>> 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/ _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
