From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GC (was: lists.texi) Date: Sat, 25 Jun 2005 11:48:54 +0200 Message-ID: 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> <87y88zv3vm.fsf@jurta.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1119690836 8611 80.91.229.2 (25 Jun 2005 09:13:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 25 Jun 2005 09:13:56 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 25 11:13:54 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dm6jK-0001D8-Nd for ged-emacs-devel@m.gmane.org; Sat, 25 Jun 2005 11:13:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dm6qX-0007GZ-98 for ged-emacs-devel@m.gmane.org; Sat, 25 Jun 2005 05:21:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dm6Ug-0000nG-Si for emacs-devel@gnu.org; Sat, 25 Jun 2005 04:58:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dm6Ud-0000lm-60 for emacs-devel@gnu.org; Sat, 25 Jun 2005 04:58:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dm6UJ-0000MY-SD for emacs-devel@gnu.org; Sat, 25 Jun 2005 04:58:08 -0400 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dm6PK-0005aF-5m for emacs-devel@gnu.org; Sat, 25 Jun 2005 04:52:58 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-202-161.inter.net.il [83.130.202.161]) by legolas.inter.net.il (MOS 3.5.8-GR) with ESMTP id ESF78747 (AUTH halo1); Sat, 25 Jun 2005 11:48:57 +0300 (IDT) Original-To: Juri Linkov In-reply-to: <87y88zv3vm.fsf@jurta.org> (message from Juri Linkov on Sat, 25 Jun 2005 00:54:05 +0300) 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:39486 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:39486 > From: Juri Linkov > Cc: teirllm@dms.auburn.edu, ttn@gnu.org, emacs-devel@gnu.org > Date: Sat, 25 Jun 2005 00:54:05 +0300 > > >> 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'm sorry to say, but you are just retracing my experience from years ago. I used to have gc-cons-threshold enlarged to 8MB, and at first it looked like a wonderful idea, exactly as you say now. But with time, I liked the effects less and less, and eventually started using the default values, which I do to this day. > Could you tell all disadvantages? (except of obvious one of memory use > which users with large memory can tolerate). It turned out to be very slow in certain cases. Unfortunately, I no longer remember the details, but please keep in mind that your observation of GC taking the same time no matter what could be true only for certain patterns of consing. It's possible, like Miles says, that my experience dates back to machines which had 64 or 128MB of memory, and it is no longer relevant nowadays (although 8MB compared to 128 is still a rather small percentage). But still, I would not recommend changing the default setting without having several developers on several different platforms run with the enlarged threshold for some prolonged period of time. > >> 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. (I always run with garbage-collection-messages set to t.) The fact that the message about GC is displayed might be evidence to what you think, but then again it might not: IIRC, Emacs always does a GC before it asks the OS for more heap. So you might see the message even if the total size of objects consed since last GC didn't cross the threshold. For example, if a package needs a large buffer, and there's not enough contiguous memory in the pool Emacs maintains, I think Emacs will GC even if the consing threshold was not crossed. > >> 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. If we find that my experience of yore is no longer relevant, I agree. But then we should probably modify the default of the threshold accordingly, instead of telling users to mess with it. For example, the default value could be dependent on the amount of installed memory.