This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Re: startup speed (or lack thereof)


On Sun, Mar 19, 2000 at 07:35:20PM +0100, Mikael Djurfeldt wrote:
> Maciej Stachowiak <mjs@eazel.com> writes:
> 
> > If removing the line and column number incrementing code really makes
> > that much performance difference, perhaps we should reconsider doing
> > this tracking. Or perhaps tracking only the line number and not the
> > column number would be sufficient; that's all other langauges provide
> > in error messages, and much of the time the column number is just
> > noise.
> 
> I think line and column number information is very important.  I run
> in an Emacs-environment where this information is used to highlight
> the erring expression.  But also in the shell, I use both line and
> column numbers.
> 
> As I wrote in a previous letter, there is a solution, however:
> 
> Rewrite the reader to operate directly on the port interface,
> i.e. directly on the port buffer.  This way, line and column numbers
> can be updated much more seldom, *and* we'll gain extra efficiency
> because of not needing to call scm_getc per character.

I have in fact been working on rewriting read.c to access the port
buffer directly. I think the reading time can be cut in half (or more)
without removing any functionality.

One question I have though is, why aren't we just using flex/bison for
parsing this stuff? It's so much work to do this manually...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]