GC (was: lists.texi)

[Juri Linkov]

> My test case constructed ten thousand times a list of size 1000,
> triggering a lot of garbage collections.  In a freshly started Emacs,
> the ring-elements function I propose to install ran the test in 11
> seconds, slightly over 5 being spent in gc.  This gives between 5 and
> 6 for the function itself.  The "abstract" version ran 37 seconds, a
> little bit over 5 in gc, giving 31 to 32 for the function itself.  In
> other words, avoiding the `ring-ref' overhead makes the function run
> more than five times faster, but the amount of consing stays the same.
>
> If I run the same test in a somewhat older Emacs, the functions
> themselves still take 5 to 6 and 31 to 32 seconds, but now they both
> spend 17.5 seconds doing gc (instead of slightly more than 5).
>
> I guess that in a really big Emacs, gc will take even much longer.  It
> is not very surprising that the more objects gc has to check, the
> longer it takes.  I believe this pretty much explains the gradual
> slowdown of Emacs as it grows older (and hence bigger).

Yes, indeed GC is what causes the slowdown.  With the option
`garbage-collection-messages' set to t, it is clearly visible that in
a big Emacs session GC takes too much time.  For example, I can see
that each GC takes about 1 sec.  The formula (/ gc-elapsed gcs-done)
with real values (/ 1788.2 1597) gives 1.12 sec.  This is substantial
time for every GC to contribute to the overall slowdown.

-- 
Juri Linkov
http://www.jurta.org/emacs/