Re: Speed or functionality in Guile? (was: Re: gc notes available)

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

Mikael Djurfeldt <mdj@nada.kth.se> writes:

 > Even though I like it when programs are efficient, I don't think speed
 > is the most important thing for an application extension language.
 > But one thing I really would like to do in an extension language is to
 > write my GUI in it.
 > 
 > If the GUI makes noticeable pauses for GC then the application won't
 > be nice to use.  Applications should be nice to use.  Therefore,
 > noticeable GC pauses excludes the use of Guile for writing GUI:s.

Which parts of the GUI are you thinking of writing in scheme?  If
you're using a widget library (Tk, GTk, Motif, etc), then I can't
imagine why setting up the widgets with scheme callbacks would
necessarily produce lots of garbage.

 > The debugging evaluator is 3 times slower than the SCM evaluator but
 > it supplies backtraces.  This is another case where speed is weighed
 > against functionality.  How often do people switch off the debugging
 > evaluator to increase evaluation speed?  Myself, I almost never do it.

I do it.  I have things like:

;;; Turn off debugging if run from the command line.
(or (null? (command-line))
    (null? (cdr (command-line)))
    (debug-disable 'debug))

in my scripts because they're way too slow with the debugging
evaluator.  In fact, they're slow even without it.

 > I realize that many users in the Guile community use Guile for batch
 > type processing or scripts where GC pauses doesn't matter.  Actually,
 > people writing GUI:s in Guile will probably be a minority.
 > 
 > But isn't GUI:s a legitimate use of Guile?
 > 
 > Should we support only the majority type of programs or should we try
 > to cover a broader range?

Again, lots of people write lots of GUI applications in STk and the
GCs don't get in the way.

 > Then, finally, a more technical point: If GC pauses are short enough
 > they won't be noticeable, and it *will* be possible to have a "stable
 > feeling" in a Guile GUI.  It might be argued that a generational GC
 > leads to short enough pauses.  But note that this is true only if
 > there isn't occasions where all generations are collected during the
 > same pause, which is the common situation in generational garbage
 > collectors.
 > 
 > This is one of the reasons why it may be a good thing to talk about
 > these issues now.

Yes and no.  If your application is truely large in the sense of using
lots of the same memory for the life of the application (e.g. - lots
of code is loaded in), then there's no reason you can't tell the
generational GC to just stop scanning this old stuff altogether.

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