Re: GC (was: lists.texi)

[Eli Zaretskii]

> From: Juri Linkov <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Sat, 25 Jun 2005 00:54:05 +0300
> 
> >> It helps to increase the value of gc-cons-threshold at least tenfolds
> >> to run slow GC less often.
> >
> > Yes, but then Emacs itself slows down, and when GC eventually
> > happens, it, too, takes a very long time.
> 
> In my tests, when I have the default gc-cons-threshold set to 400000,
> GC takes 1 sec.  When I increase it 100 times to 40000000, GC takes
> the same 1 sec (and not 100 sec as if there were linear dependence).
> And there is no slowdown.

I'm sorry to say, but you are just retracing my experience from years
ago.  I used to have gc-cons-threshold enlarged to 8MB, and at first
it looked like a wonderful idea, exactly as you say now.  But with
time, I liked the effects less and less, and eventually started using
the default values, which I do to this day.

> Could you tell all disadvantages? (except of obvious one of memory use
> which users with large memory can tolerate).

It turned out to be very slow in certain cases.  Unfortunately, I no
longer remember the details, but please keep in mind that your
observation of GC taking the same time no matter what could be true
only for certain patterns of consing.

It's possible, like Miles says, that my experience dates back to
machines which had 64 or 128MB of memory, and it is no longer relevant
nowadays (although 8MB compared to 128 is still a rather small
percentage).  But still, I would not recommend changing the default
setting without having several developers on several different
platforms run with the enlarged threshold for some prolonged period of
time.

> >> Currently it suggests increasing `gc-cons-threshold' for a program
> >> that creates lots of Lisp data.  There are too many such Emacs
> >> packages
> >
> > As long as ``lots of Lisp data'' isn't defined in some quantitative
> > terms, one cannot claim that ``too many Emacs packages'' do this.
> 
> In quantitative terms ``lots of Lisp data'' could mean the default
> value of `gc-cons-threshold'.  Then ``too many Emacs packages'' means
> that with garbage-collection-messages equal to t, many Emacs commands
> display the ``Garbage collecting...'' message.

(I always run with garbage-collection-messages set to t.)  The fact
that the message about GC is displayed might be evidence to what you
think, but then again it might not: IIRC, Emacs always does a GC
before it asks the OS for more heap.  So you might see the message
even if the total size of objects consed since last GC didn't cross
the threshold.  For example, if a package needs a large buffer, and
there's not enough contiguous memory in the pool Emacs maintains, I
think Emacs will GC even if the consing threshold was not crossed.

> >> The advice for this problem could be the same: to set
> >> `gc-cons-threshold' to a larger value.
> >
> > Based on my experience, I would object to such advice.
> 
> Your advice to look at `gc-cons-threshold' helped me enormously.
> Now with a large value of `gc-cons-threshold' I have no slowdown
> anymore.  It would be good to share this information with other
> Emacs users by mentioning it in the documentation.

If we find that my experience of yore is no longer relevant, I agree.
But then we should probably modify the default of the threshold
accordingly, instead of telling users to mess with it.  For example,
the default value could be dependent on the amount of installed
memory.