Re: Guile & PR

[hjstein@bfr.co.il (Harvey J. Stein)]

Per Bothner <bothner@cygnus.com> writes:

 > If you also consider implementations that compile to an internal
 > format (such as bytecode), that is not consistent with my limited
 > benchmarks.  Scheme48 is much faster, and Kawa is also noticeably
 > faster.  See:
 > http://sourceware.cygnus.com/kawa/papers/KawaLisp98-html/x1005.html
 > 
 > I used the "default" setup for Guile, so I assume I got the
 > debugging evaluator.

There it is again - another reason to ship with debugging off.

Facts:

1. Speed complaints keep occurring over & over & over again.
2. One reason for slowness is that debugging is on by default.
3. There's no way for a luser to turn off debugging for
   *all* guile apps on his system.
4. Guile is supposed to be used in lots of applications.
5. Another reason for slowness is the last official release has a
   bug in the reading code (which is easily repaired).
6. If you load code with debugging turned on & then turn it off, it
   will run slower than if you started up with debugging turned off.
7. Another reason for slowness is the gobs of code read in at startup
   & the effects it has on the heap (interaction with gc) and on code
   reading itself.

Based on these facts, I'd draw the following conclusions:

1. One should make a new official release available with debugging
   turned off.
2. One should make a new official release available with the read bug
   fixed.
3. One should make a new official release available with a fix for the
   slow startup.

Regarding point 3, a number of people have made a number of fixes
available, including hand coding part or all of boot-9 in C, using
hobbit to compile all the startup code, etc.  One of these solutions
(hopefully the one which minimizes startup & execution time) should
just be adopted & used until either the "correct" solution (aka the
new module system + new gc, aka godot+ (for good reason)) is completed
or until hell freezes over, whichever comes first, and these days I'm
giving 2-1 odds on the latter.

Can anyone explain to me why potentially tens of thousands of users,
if not more, should all be using a guile which suffers from these
performance killers?  This would also be known as a guile not suitable
for a large class of applications because of its performance
characteristics.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il