This is the mail archive of the guile@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: gc notes available


Russ McManus <russell.mcmanus@gs.com> writes:

> I think it is a basic requirement for guile to be able to work with
> large data sets.  Without some form of generational gc, gc time starts
> to dominate run time, so I think we need a generational gc.  I'm not
> sure if this means a vote for 1 or 2!

Both 1 and 2 are compatible with a generational gc.

> With a generational gc, you sometimes get a scan of the whole data
> space, which will necessarily be slow when the data set is large.  So
> I don't know how to get around occassional long pauses, so I think
> I'm still voting for 2.  But if 1 has the ability to handle large
> data sets, then I would vote for that one instead.

1 would be able to handle large data sets and would have a performance
which scales as well as 2 when the problem size grows.

The difference is that 1 would be slower than 2 by a constant factor
because it has to do more bookkeeping.  A wild guess would be that 1
would have 20-25% longer execution time.

What I'm trying to argue in this discussion is that the difference
between 1 and 2 with regard to execution speed is a difference in
degree while 2 makes it hard to write GUI:s with a nice behaviour,
that is, it excludes one class of application of Guile.

> BTW, I use guile right now for GUI programs (linked into Motif
> programs), and the collections are noticeable to the user, so
> improvements in this area are very welcome!

Well, this is my experience too.  I wonder if those who argue for
alternative 2 really have tried to write larger user interfaces in
Guile...  (with exception of Harvey Stein who have managed to get
smooth performance in STk by using a larger initial heap and calling
gc in the scheme code).

/mdj