On Feb 16, 2013, at 2:14 PM, Jim Ursetto wrote: > On Feb 16, 2013, at 8:54, Peter Bex <peter....@xs4all.nl> 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 _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers