Re: GC (was: lists.texi)

[Juri Linkov]

>> 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 used to run with gc-cons-threshold customized to a very large value,
> but stopped doing that, since the advantages were far too minor and
> disadvantages far too annoying.

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

>> Anyway, it would be good to mention this problem in the elisp manual.
>
> You mean, user's manual, right?  This has nothing to do with Lisp
> programming, it's a usage issue.

No.  `gc-cons-threshold' and advice for its usage are documented in
the Emacs Lisp reference manual.  I don't object to documenting it
in the user's manual as well.

>> 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.

>> In addition to this problem, the manual could also mention the
>> problem of GC duration increasing with the size of allocated Lisp
>> objects.
>
> Isn't it obvious that GC, at least its mark phase, is approximately
> linear in the number of live Lisp objects?

Yes, GC is linear in the number of *live* Lisp objects, but not garbage.
IIUC, the number of live objects GC traverses doesn't depend on the
value of `gc-cons-threshold'.

>> 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.

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