[racket] string-strip

From: Marijn (hkBst at gentoo.org)
Date: Wed Jan 11 08:54:18 EST 2012

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,


Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Posted on the users mailing list.