From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Newsgroups: gmane.emacs.devel Subject: Re: Windows: Emacs 24.1 binary size vs 24.2 binary size Date: Mon, 10 Sep 2012 23:00:54 -0600 Message-ID: References: <503D7C5B.4080701@gmail.com> <504219DA.20309@gmail.com> <83pq65g5lx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=485b397dd5bd7bc31404c965f501 X-Trace: ger.gmane.org 1347339662 4942 80.91.229.3 (11 Sep 2012 05:01:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Sep 2012 05:01:02 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 11 07:01:05 2012 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 1TBIau-0006sN-Uq for ged-emacs-devel@m.gmane.org; Tue, 11 Sep 2012 07:01:05 +0200 Original-Received: from localhost ([::1]:32988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBIar-0004cw-9U for ged-emacs-devel@m.gmane.org; Tue, 11 Sep 2012 01:01:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBIao-0004ce-DQ for emacs-devel@gnu.org; Tue, 11 Sep 2012 01:00:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBIam-0005oq-E4 for emacs-devel@gnu.org; Tue, 11 Sep 2012 01:00:58 -0400 Original-Received: from mail-qc0-f169.google.com ([209.85.216.169]:63583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBIak-0005oX-Tm; Tue, 11 Sep 2012 01:00:54 -0400 Original-Received: by qcsd16 with SMTP id d16so62880qcs.0 for ; Mon, 10 Sep 2012 22:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q9pWJlRkEundKnFZUljAWOayiuGEmZuwUWSuad8Pd9Y=; b=rTqtMvjSJIizEDGJnEuUHZHqwZ9ymBecu87RAnjVBbknO2mK22FK14DcfGELnEuN+P bOiaaAtfQocTnc5I2J4ZRRNeRW8dHeIiVNrClkAkNH5il/vpv6N+S5enUvA74kRrbpqH r5H9BPl0jok/XI66D3lpoqNaUVeTKk0QUMqW+sav1AGxHnAxLJco1xjHEQW417W7pWm6 /8+WKA6QW/3Ow5Wras6+Ll7TtysKqCX1xhw6atX79P5pzpQ4/db4PumV5VEzeLOhsOZq 5E2cfItDOHub0CiBdbm6KfuBi4MQRLN5BTsT7aaxPi7NnerycYJCz4JMT/0+3Z/KjqbW pF7g== Original-Received: by 10.224.186.203 with SMTP id ct11mr17430508qab.80.1347339654251; Mon, 10 Sep 2012 22:00:54 -0700 (PDT) Original-Received: by 10.49.97.230 with HTTP; Mon, 10 Sep 2012 22:00:54 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.169 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:153231 Archived-At: --485b397dd5bd7bc31404c965f501 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 10, 2012 at 8:58 AM, Stefan Monnier wrote: > That sounds weird, indeed. An explanation that comes to my mind > goes along the following lines: > > little change in code > => slight change in some part of the dump process > => memory allocation pattern at that point is different > => some memory zone that used to be `free'able now can't be freed any > more because some surviving object is now placed in that zone rather > in some other zone. Interesting. > IOW the actual live data is pretty much the same, but the larger binary > has a lot more memory that's "allocated from the OS but kept in some > free list". How do the > > Pure-hashed: > Dumping under the name emacs > pure bytes used > > compare between the two builds? I'll check and report back. --485b397dd5bd7bc31404c965f501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 10, 2012 at 8:58 AM, Stefan Monnier = <monnier@iro.umontreal.ca> wrote:
That sounds weird, indeed. =A0An explanation that comes to my mind
goes along the following lines:

=A0 =A0little change in code
=A0 =A0=3D> slight change in some part of the dump process
=A0 =A0=3D> memory allocation pattern at that point is different
=A0 =A0=3D> some memory zone that used to be `free'able now can'= t be freed any
=A0 =A0 =A0 more because some surviving object is now placed in that zone r= ather
=A0 =A0 =A0 in some other zone.

Interesting= .
=A0
=A0
IOW the actual live data is pretty much the same, but the larger binary
has a lot more memory that's "allocated from the OS but kept in so= me
free list". =A0How do the

=A0 =A0Pure-hashed: <FOO>
=A0 =A0Dumping under the name emacs
=A0 =A0<BAR> pure bytes used

compare between the two builds?

I'll ch= eck and report back.
--485b397dd5bd7bc31404c965f501--