chicken-hackers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]