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)



> 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.

Indeed, read.c was one of the big reasons for doing the new port
system in the first place.  If we can hack in optimized code for the
most commonly seen objects --- lists, symbols, numbers, strings ---
it seems to me we could go very fast.

I think Gary's right that the interface will continue to change, but I
think we should go ahead and optimize read.c now.  I don't think we'll
suffer too much in the big picture.

> 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...

Well, we need to be sure that they both generate namespace-clean
code.  If that's okay, and they're fast enough, I don't know of any
real reason not to use them.  They're widely available, and you can
ship pre-built C files.

One minor issue is that the natural way to parse lists in Bison is
left-recursive, while lists are right-recursive data structures.  If
you write a right-recursive grammar, you get deep Bison stacks.  But
I'm sure that can be coped with somehow.  I guess you could write a
left-recursive rule that builds the list using set-cdr!.  A
generational GC would just love that...

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