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

[Mikael Djurfeldt <mdj@nada.kth.se>]

hjstein@bfr.co.il (Harvey J. Stein) writes:

> 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 thing which makes GC pauses a trouble for many people is that
scheme is called at all.  Even if you only have callbacks, cells will
be allocated on the heap.  If you don't do any tricks with the garbage
collector (I think most people don't want to care about the garbage
collector) a GC pause may be generated if we don't have the right kind
of collector.

I gave an example which have even greater demands on the GC in a
previous posting: When I analyze data from my simulator I follow a
sequence of events in slowed down time.  I might for example look at
how membrane potentials or calcium ion concentrations spread over a
nerve cell after a spike.  I want to be able to represent the cell as
a pseudo-colored graph of segments where the colors change over time.
Since there usually aren't more than 10-20 segments it shouldn't be a
problem to handle this on the Scheme level in some kind of canvas
widget.  But, at least with the current collector, this is not
possible due to GC pauses which disturb the smooth flow of scaled-down
time.

I think this kind of dynamic presentation of data will be more common
in future applications.  Also, GUI:s seems to have more animated
components which can add to

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

Well, I guess I should test some larger STk GUI:s to verify your
claim.  If they have smooth behaviour I'll have to find out what is
the difference compared to those I've written for Guile...

/mdj