-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28-12-11 19:27, Neil Van Dyke wrote: > Marijn wrote at 12/28/2011 12:00 PM: >> I don't think my use of this code is very performance, but I >> couldn't help myself, so I looked into making it faster > > This is the best spirit. :) > >> What I found was that it is much slower to treat a string as a >> port and then read-char from that then it is to directly index >> the string. > > That string input ports are often noticeably slower than string > indexing is one of the banes of my existence. Most reading and > parsing operations you implement, you want to work on both ports > and strings. But, if you first write a procedure that works on a > port, and then write a wrapper procedure that works on a string (by > doing an "open-input-string" and calling your procedure that works > on ports), the string one can be noticeably slower than if you'd > handwritten the string one. But having to write two separate > procedures has big development cost, and I always just take the > performance hit on strings instead, or write a string procedure and > then not have a port procedure when I need it later. One approach > that might help is to design a macro that lets people define > processing on strings and ports, and expands to produce two closure > definitions -- one that works on ports, and one on strings, and > avoids a lot of port-related overhead in the string one.
Matthew, any comments on this? Is there a fundamental reason that treating a string as a port is so much slower than direct indexing or is there something that can be done about it? Or should we look into automatically duplicating code with macros? Marijn >> In the end I was able to construct code that is another factor >> 5.5 faster than your version: >> > > Marijn, that's a great implementation. > > And it's encouraging to see that forgoing regexps and > "string->number", and doing a character-by-character DFA, is faster > in this case. It's pretty common in interpreted languages to use > regexps for performance reasons; nice when we see that pure Racket > code can be faster. > > One tangential comment: I don't think it's significant in this > situation, but I believe that "case" is currently slower than, > say, people coming from a C background might think. So, sometimes, > if one really wants to micro-optimize, one sometimes might be > better off doing, say strategic "if"s and arithmetic, instead of > "case". > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78LIsACgkQp/VmCx0OL2x7hQCfb77YNdgro1gKb3hhUxYQ+za7 hfAAnRwlJ2qdTOCZbNuyZvFZw34oDebI =AyrQ -----END PGP SIGNATURE----- ____________________ Racket Users list: http://lists.racket-lang.org/users
