[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC (was: lists.texi)
From: |
Juri Linkov |
Subject: |
Re: GC (was: lists.texi) |
Date: |
Sat, 25 Jun 2005 00:54:05 +0300 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
>> 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/
- Re: lists.texi, (continued)
- Re: lists.texi, Luc Teirlinck, 2005/06/21
- Re: lists.texi, Thien-Thi Nguyen, 2005/06/21
- Re: lists.texi, Juri Linkov, 2005/06/22
- Re: lists.texi, Eli Zaretskii, 2005/06/22
- Re: lists.texi, Luc Teirlinck, 2005/06/22
- Re: lists.texi, Luc Teirlinck, 2005/06/22
- Re: lists.texi, Richard M. Stallman, 2005/06/23
- GC (was: lists.texi), Juri Linkov, 2005/06/24
- GC (was: lists.texi), Juri Linkov, 2005/06/24
- Re: GC (was: lists.texi), Eli Zaretskii, 2005/06/24
- Re: GC (was: lists.texi),
Juri Linkov <=
- Re: GC (was: lists.texi), Luc Teirlinck, 2005/06/24
- Re: GC (was: lists.texi), Miles Bader, 2005/06/24
- Re: GC (was: lists.texi), Eli Zaretskii, 2005/06/25
- Re: GC, Adrian Aichner, 2005/06/25
- Re: GC, Miles Bader, 2005/06/25
- Re: GC, Adrian Aichner, 2005/06/25
- Re: GC, Miles Bader, 2005/06/25
- Re: GC, Adrian Aichner, 2005/06/26
- Re: GC, Eli Zaretskii, 2005/06/26
- Re: GC, Juri Linkov, 2005/06/26