[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GC (was: lists.texi)

From: Eli Zaretskii
Subject: Re: GC (was: lists.texi)
Date: Fri, 24 Jun 2005 23:08:00 +0200

> From: Juri Linkov <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Fri, 24 Jun 2005 22:02:52 +0300
> >> I noticed too that in sufficiently long Emacs sessions Lisp
> >> evaluation slows down.
> >
> > One possible situation where this could happen is if you customize
> > gc-cons-threshold to a large number.
> Do you actually mean gc-cons-threshold customized to a *small* number?

No, I meant what I wrote.

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

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.

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]