> From: Juri Linkov <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], 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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
