This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Benchmarking large scores 1.3.4 vs 1.3.5
- To: Jan Nieuwenhuizen <janneke at gnu dot org>
- Subject: Re: Benchmarking large scores 1.3.4 vs 1.3.5
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 14 Jun 2000 11:34:00 +0200
- Cc: guile at sourceware dot cygnus dot com, "ir. Wendy" <hanwen at cs dot uu dot nl>
- Cc: djurfeldt at nada dot kth dot se
- References: <200006140839.KAA20376@appel.dyndns.org>
Jan Nieuwenhuizen <janneke@gnu.org> writes:
> In short, for small scores results are comparable, but for large scores
> (no swapping, though), 1.3.5 is much memory-frienlier (about 1/5 less
> memory), whereas the processing time shoots up by a factor 3.5.
> This probably is a LilyPond thing, but it would be good if someone
> would benchmark with large applications.
Recent 1.3.5's have a new policy for triggering heap allocation and
determining the sizes of heap segments. It fixes a number of problems
in the old GC:
1. Couldn't handle two separate pools of cells. (Would run wild,
allocating memory for certain programs.)
2. Would sometimes allocate far too much heap so that the Guile
process became gigantic.
3. Would sometimes allocate too little so that too much time was spent
in GC.
4. Would often trigger heap allocation several times in a row. (The
new scheme predicts how large the segments needs to be in order not
to need further allocation.)
The new GC scheme also is prepared for POSIX threading.
It was introduced in March this year.