[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Slowdown in switch to card-based collector?

From: Mikael Djurfeldt
Subject: Slowdown in switch to card-based collector?
Date: Thu, 26 Oct 2000 20:21:48 +0200

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

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]