-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29-12-11 10:02, Marijn wrote: >>> 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?
Hi Matthew, I would still like to hear your comments on this, Marijn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8NlIoACgkQp/VmCx0OL2yiaQCfU8Iv/8phG2PVM2Sb1eWqN+61 e0oAnRYpNh7g1NgLy9OUNMphpBBZuU3n =0tLH -----END PGP SIGNATURE----- ____________________ Racket Users list: http://lists.racket-lang.org/users
