[racket] string-strip

-----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-----