On Wed, Mar 27, 2013 at 11:50:20PM -0500, Jim Ursetto wrote: > On Feb 16, 2013, at 2:14 PM, Jim Ursetto wrote: > > On Feb 16, 2013, at 8:54, Peter Bex <[email protected]> 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 that case, I'd appreciate it if someone would push this patch so we can close the ticket. > Unfortunately, I think it is essentially impossible at this time to have the > compiler do [inlining] 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. This all sounds rather hairy, I agree it's probably not worth the effort. Thank you for the analysis, and showing where the main bottleneck is. At least we know where to concentrate our efforts now :) Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
