[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] Restore row and column counting for ports (fixes #978) |
Date: |
Thu, 28 Mar 2013 09:18:01 +0100 |
User-agent: |
Mutt/1.4.2.3i |
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 <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 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