From: Juri Linkov <juri@jurta.org>
Cc: ttn@gnu.org, teirllm@dms.auburn.edu, emacs-devel@gnu.org
Subject: Re: GC (was: lists.texi)
Date: Sat, 25 Jun 2005 00:54:05 +0300 [thread overview]
Message-ID: <87y88zv3vm.fsf@jurta.org> (raw)
In-Reply-To: <u3br7h39r.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Jun 2005 23:08:00 +0200")
>> 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/
next prev parent reply other threads:[~2005-06-24 21:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-18 23:19 lists.texi Luc Teirlinck
2005-06-19 0:01 ` lists.texi Luc Teirlinck
2005-06-19 0:15 ` lists.texi Luc Teirlinck
2005-06-19 0:37 ` lists.texi Luc Teirlinck
2005-06-19 6:37 ` lists.texi David Kastrup
2005-06-19 15:55 ` lists.texi Richard Stallman
2005-06-19 17:47 ` lists.texi Luc Teirlinck
2005-06-20 17:52 ` lists.texi Richard Stallman
2005-06-20 23:12 ` lists.texi Luc Teirlinck
2005-06-21 5:13 ` lists.texi David Kastrup
2005-06-21 15:13 ` lists.texi Richard M. Stallman
2005-06-21 16:35 ` lists.texi Thien-Thi Nguyen
2005-06-21 19:00 ` lists.texi Luc Teirlinck
2005-06-21 21:56 ` lists.texi Thien-Thi Nguyen
2005-06-21 19:45 ` lists.texi Luc Teirlinck
2005-06-21 20:58 ` lists.texi Luc Teirlinck
2005-06-21 22:09 ` lists.texi Thien-Thi Nguyen
2005-06-22 16:28 ` lists.texi Juri Linkov
2005-06-22 19:27 ` lists.texi Eli Zaretskii
2005-06-22 18:44 ` lists.texi Luc Teirlinck
2005-06-22 20:25 ` lists.texi Luc Teirlinck
2005-06-23 16:53 ` lists.texi Richard M. Stallman
2005-06-24 19:02 ` GC (was: lists.texi) Juri Linkov
2005-06-24 19:02 ` Juri Linkov
2005-06-24 21:08 ` Eli Zaretskii
2005-06-24 21:54 ` Juri Linkov [this message]
2005-06-24 23:52 ` Luc Teirlinck
2005-06-25 0:51 ` Miles Bader
2005-06-25 9:48 ` Eli Zaretskii
2005-06-25 11:58 ` GC Adrian Aichner
2005-06-25 12:53 ` GC Miles Bader
2005-06-25 21:53 ` GC Adrian Aichner
2005-06-26 0:02 ` GC Miles Bader
2005-06-26 8:20 ` GC Adrian Aichner
2005-06-26 18:51 ` GC Eli Zaretskii
2005-06-26 23:43 ` GC Juri Linkov
2005-06-27 5:38 ` GC Richard M. Stallman
2005-06-26 22:42 ` GC Richard M. Stallman
2005-06-25 12:15 ` GC (was: lists.texi) Miles Bader
2005-06-25 13:10 ` GC Gaëtan LEURENT
2005-06-25 14:48 ` GC Eli Zaretskii
2005-06-25 14:45 ` GC (was: lists.texi) Eli Zaretskii
2005-06-25 16:40 ` Richard M. Stallman
2005-06-28 4:55 ` GC Stefan Monnier
2005-06-28 21:29 ` GC Richard M. Stallman
2005-07-11 17:00 ` GC Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y88zv3vm.fsf@jurta.org \
--to=juri@jurta.org \
--cc=emacs-devel@gnu.org \
--cc=teirllm@dms.auburn.edu \
--cc=ttn@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).