From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Default history-length should be higher Date: Sun, 26 Jan 2014 18:52:22 -0500 Message-ID: References: <7a6753c5-cac9-4e60-be73-42467784e8eb@default> <8761p7uykd.fsf@maru2.md5i.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390780359 11240 80.91.229.3 (26 Jan 2014 23:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 23:52:39 +0000 (UTC) Cc: Michael Welsh Duggan , emacs-devel To: Bozhidar Batsov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 27 00:52:45 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7ZVJ-0001XA-Sv for ged-emacs-devel@m.gmane.org; Mon, 27 Jan 2014 00:52:42 +0100 Original-Received: from localhost ([::1]:56732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7ZVJ-00022D-Dd for ged-emacs-devel@m.gmane.org; Sun, 26 Jan 2014 18:52:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7ZV9-000225-9q for emacs-devel@gnu.org; Sun, 26 Jan 2014 18:52:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7ZV2-0008W5-0b for emacs-devel@gnu.org; Sun, 26 Jan 2014 18:52:31 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7ZV1-0008W1-Si for emacs-devel@gnu.org; Sun, 26 Jan 2014 18:52:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxJeN/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFxJeN/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46121176" Original-Received: from 69-196-151-141.dsl.teksavvy.com (HELO pastel.home) ([69.196.151.141]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Jan 2014 18:52:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9EB566020E; Sun, 26 Jan 2014 18:52:22 -0500 (EST) In-Reply-To: (Bozhidar Batsov's message of "Sun, 26 Jan 2014 21:22:37 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169153 Archived-At: > Code that creates a lot of objects would obviously be impacted > significantly, since GC would be performed frequently. C-h v gc- TAB will show you that gc-cons-threshold is only one part of the story. As soon as the heap grows, gc-cons-percentage takes over. I.e. by default, if your heap is 100MB big, GC will take place every 10MB (rather than every 0.8MB) of allocation. Of course, maybe we should increase gc-cons-percentage. But part of the reason for wanting frequent GCs is to try and mitigate the effects of fragmentation. So, a higher gc-cons-threshold might speed up initialization of `flx' but it might also cause your Emacs session to use more VSZ and RSS, which will also tend to make each GC slower. In reality for code that just allocates a large data-structure and not much else, the best option is "never GC" (since every GC will just waste time, since we only allocated but not freed anything), although clearly in general this is not a good option. In the case of `flx', maybe the best option is for it to let-bind gc-cons-threshold around the code that "allocates without freeing". Stefan