From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: GC (was: lists.texi) Date: Sat, 25 Jun 2005 00:54:05 +0300 Organization: JURTA Message-ID: <87y88zv3vm.fsf@jurta.org> References: <200506182319.j5INJWF08937@raven.dms.auburn.edu> <200506190015.j5J0FQk09223@raven.dms.auburn.edu> <200506190037.j5J0b9Y09287@raven.dms.auburn.edu> <200506191747.j5JHlha11521@raven.dms.auburn.edu> <200506202312.j5KNCct19091@raven.dms.auburn.edu> <200506212058.j5LKw5P23961@raven.dms.auburn.edu> <874qbqh0lm.fsf@jurta.org> <87mzpf3a5v.fsf_-_@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1119651188 1896 80.91.229.2 (24 Jun 2005 22:13:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2005 22:13:08 +0000 (UTC) Cc: ttn@gnu.org, teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 25 00:12:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DlwDF-0007qg-03 for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2005 23:59:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DlwKL-00077w-QH for ged-emacs-devel@m.gmane.org; Fri, 24 Jun 2005 18:07:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DlwFH-0004SF-MD for emacs-devel@gnu.org; Fri, 24 Jun 2005 18:01:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DlwF0-0004Ke-4Z for emacs-devel@gnu.org; Fri, 24 Jun 2005 18:01:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DlwEz-0004JZ-Sk for emacs-devel@gnu.org; Fri, 24 Jun 2005 18:01:37 -0400 Original-Received: from [194.126.101.111] (helo=mail.neti.ee) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DlwDx-0007aP-N0; Fri, 24 Jun 2005 18:00:34 -0400 Original-Received: from mail.neti.ee (80-235-38-217-dsl.mus.estpak.ee [80.235.38.217]) by Relayhost1.neti.ee (Postfix) with ESMTP id 899BA1EAE; Sat, 25 Jun 2005 00:56:44 +0300 (EEST) Original-To: Eli Zaretskii In-Reply-To: (Eli Zaretskii's message of "Fri, 24 Jun 2005 23:08:00 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:39462 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39462 >> 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/