Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports (fixes #978)

[Jim Ursetto]

On Feb 16, 2013, at 2:14 PM, Jim Ursetto wrote:

> On Feb 16, 2013, at 8:54, Peter Bex <address@hidden> wrote:
> 
>> Just removing the port position bookkeeping altogether is better, I
>> think.  I haven't done any benchmarks but Chicken's notoriously awful
>> I/O performance might partially be due to the port position bookkeeping.
> 
> I seriously doubt that; it's more likely all the indirection (and Scheme 
> code) that happens for each character when you call read-char.  read-string 
> and read-line are not subject to this as they read chunks at a time in C.  
> (And now that read-line reads into a static buffer it is very fast, not quite 
> at Perl speed.)

I had a look into this a few weeks ago and found that the impact of port 
position bookkeeping is indeed virtually nil, being dwarfed by the cost of 
procedure entry, checking for stack space and interrupts, etc.  So we are okay 
here.

> In my opinion a better solution would be to have the compiler figure out when 
> it is dealing with a file port etc. and inline the code to read-char (e.g. 
> getc) based on the port type.  It seems like this should be doable in the 
> flow analysis pass, but I don't know for sure. 

I also looked at this possibility.

First I measured the maximum possible speedup for string ports by manually 
inlining much of the read-char code, rather than have it call the read-char 
procedure through the port slot.  This led to a speedup of about 3x, which is 
not bad.

Additionally, in one situation I measured the speedup at 20x.  This happens 
when the read-char loop is tight enough such that there is no stack allocation 
or calls to closures (inlined procedures don't count).  In this case the 
compiler can generate a goto loop; and avoid interrupt and stack checks.  
Although this situation would not typically arise in normal Scheme code (like a 
character-by-character parser) it could happen in specialized code such as a 
base64 reader.

The only downside is possible code bloat due to inlining of every read-char.

The benchmarks are here:

http://paste.call-cc.org/paste?id=c491419d28381fd01a7ff5c18f763ab087a5e659

Unfortunately, I think it is essentially impossible at this time to have the 
compiler do this automatically via type analysis.  I believe it is possible to 
get the compiler to treat string ports, for example, as a separate type and 
specialize on that.  However, once you do this, you cannot use the existing 
procedures (such as close-input-port) which specialize on plain input-ports and 
output-ports, as there's no way to say that a particular type 
(string-input-port) is derived from another type (input-port) and is valid in 
lieu of the base type.

Also, as far as I know you can't extend existing definitions to add new 
specializations.  So, you would have to rewrite every port-related type 
definition to accept plain ports, string-ports, and every other specialized 
type of port.

So this looks like a no-go at the moment.  But if I am missing something and it 
is doable, then it is probably worth experimenting with.

Jim