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: (heap 1024 82721 1933216) Date: Sat, 18 Jan 2014 23:19:02 -0500 Message-ID: References: <52DA8412.2080009@dancol.org> <52DB472B.5060805@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390105155 27271 80.91.229.3 (19 Jan 2014 04:19:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 04:19:15 +0000 (UTC) Cc: Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 05:19:22 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 1W4jqy-0007N9-NO for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 05:19:20 +0100 Original-Received: from localhost ([::1]:45093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jqy-00017j-9J for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 23:19:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jqo-00017X-KT for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:19:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4jqh-0001I7-C1 for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:19:10 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:28890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4jqh-0001I1-8g for emacs-devel@gnu.org; Sat, 18 Jan 2014 23:19:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFpaEg/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCw4mEhQYDSSIHgbBLZEKA4hhlweFEoFegxU X-IPAS-Result: Av8EABK/CFFFpaEg/2dsb2JhbABEuzWDWRdzgh4BAQQBViMQCw4mEhQYDSSIHgbBLZEKA4hhlweFEoFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45296287" Original-Received: from 69-165-161-32.dsl.teksavvy.com (HELO pastel.home) ([69.165.161.32]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jan 2014 23:19:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 2D8EC60281; Sat, 18 Jan 2014 23:19:02 -0500 (EST) In-Reply-To: <52DB472B.5060805@dancol.org> (Daniel Colascione's message of "Sat, 18 Jan 2014 19:31:55 -0800") 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:168717 Archived-At: >> Could be. For an Emacs that grew to 6GB, I don't find it worrisome >> if it doesn't shrink back below 2GB. [...] > Longer-term, it would be nice to be able to compact objects. We could move > objects during the unmark phase of GC by looking for forwarding pointers to > new object locations. (Of course, objects found through conservative > scanning would have to be considered pinned.) Lots of work for *very* little benefit. I've pretty much never seen a case where a user is really annoyed just by Emacs's size "after freeing everything". In pretty much all cases, the user was already annoyed at Emacs's size *before* freeing everything, so that's the problem to solve. Once this problem is solved, the fact that the memory is not very much returned to the OS is usually not a problem any more. >> I'm much more worried about: how on earth did it grow to 6GB? > I have no idea --- I was just doing normal editing over a few dozen files. Yet, *that* is the problem. The fact that freeing everything didn't let you work around this problem is of very little concern. So if you ever bump into such a situation, don't bother trying to free stuff, and instead try and figure out what is eating all that memory. Stefan