Slowdown in switch to card-based collector?

[Mikael Djurfeldt]

When using a simple test program (couldn't find it, can anyone point
me to it?), the card based collector showed slightly better
performance than the old GC.

I've now benchmarked a real application (a neural simulation) loading
approx. two dozen modules and heavily using GOOPS.  The application
had a 5 Mb heap and ran using the normal evaluator.

I statically linked the application against

1. libguile from 2000-08-13 (old GC)
2. libguile from 2000-10-26 (new GC + GOOPS builtin)

(Yes, I know I should have linked against libraries directly on either
side of the GC change.  Practical considerations made me do otherwise.
Besides, to get a first warning, it gives more information to cover
the entire period---there could be a problem in some later change as
well.)

The fact that GOOPS was merged in 2 should only have positive effects
since nothing extra was added but some overhead was removed.

All timings were made using a shell script which ran the tests without
pauses.  The two binaries were tested in an interlaced order
(ABABABAB).

Lots of system resources are used throughout the simulation.  For
example, there is a tcltk-based display drawing data during the
simulation.

The following figures were obtained by running the shell command
`time', that is it includes application startup.

Total execution time in seconds

2000-08-13      2000-10-26

46.890          48.960
46.998          48.899
46.780          48.949
46.832          49.140
======          ======
46.875          48.987

=> 4.5 % total slowdown

The following figures were obtained by using Guile's internal timing
functions around the call which performs the actual simulation.

non-GC time (ms)           GC time (ms)

08-13   10-26   change(%)  08-13   10-26   change(%)

13220   13450   +1.74      25370   27330   +7.73
13100   13460   +2.75      25470   27360   +7.42
12940   13420   +3.71      25390   27480   +8.23
12770   13440   +5.25      25610   27440   +7.15

=> The major cause seems to be a 7-8% slowdown of the garbage
   collector.

Of course these figures should only be seen as a warning.  We need to
run other large applications to know for sure.