GNU bug report logs - #6006
recent emacs binary size increase by 800KB

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6006 in the body.
You can then email your comments to 6006 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: recent emacs binary size increase by 800KB
Date: Thu, 22 Apr 2010 13:13:50 -0400

Looking at recent emacs builds:

$ ls -l emacs-24*
-rwx------ 1 dann dann 7541146 Apr 15 16:04 emacs-24.0.50.1*
-rwx------ 1 dann dann 7545209 Apr 15 17:49 emacs-24.0.50.2*
-rwx------ 3 dann dann 8405343 Apr 18 15:53 emacs-24.0.50.3*

$ size -f emacs-24*
   text    data     bss     dec     hex filename
1847515 5426628       0 7274143  6efe9f emacs-24.0.50.1
1848083 5430148       0 7278231  6f0e97 emacs-24.0.50.2
1848275 6290116       0 8138391  7c2e97 emacs-24.0.50.3

The "data" segment size has increased between the .2 and .3 version by 800KB.

The change responsible seems to be this:

2010-04-18  Stefan Monnier  <monnier <at> iro.umontreal.ca>

            * loadup.el: Setup hash-cons for pure data.

Message #6 received at 6006 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: 6006 <at> debbugs.gnu.org
Subject: Re: bug#6006: recent emacs binary size increase by 800KB
Date: Thu, 22 Apr 2010 15:35:00 -0400

> The "data" segment size has increased between the .2 and .3 version
> by 800KB.
[...]
>             * loadup.el: Setup hash-cons for pure data.

Yes, this patch makes Emacs use free up a fairly large hash-table just
before dumping, so its image is larger, with a fair amount of memory
that's not actually used (it's still allocated to the Emacs process but
Emacs has it registered as "free for reuse").

Some of that memory can be recovered by adjusting the size of the
pure-space (since the patch reduces the pure-space usage but didn't
reduce the redefined size of the pure space), but not all.

This said, I don't think it's a real problem since that memory is not
really wasted (it will be used when Emacs starts to allocate), other
than on the disk.


        Stefan

Message #9 received at 6006 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 6006 <at> debbugs.gnu.org
Subject: Re: bug#6006: recent emacs binary size increase by 800KB
Date: Thu, 22 Apr 2010 16:45:16 -0400

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> The "data" segment size has increased between the .2 and .3 version
>> by 800KB.
> [...]
>>             * loadup.el: Setup hash-cons for pure data.
>
> Yes, this patch makes Emacs use free up a fairly large hash-table just
> before dumping, so its image is larger, with a fair amount of memory
> that's not actually used (it's still allocated to the Emacs process but
> Emacs has it registered as "free for reuse").
>
> Some of that memory can be recovered by adjusting the size of the
> pure-space (since the patch reduces the pure-space usage but didn't
> reduce the redefined size of the pure space), but not all.
>
> This said, I don't think it's a real problem since that memory is not
> really wasted (it will be used when Emacs starts to allocate), other
> than on the disk.

Part of that memory will be read from the disk at start up....
What if you allocate the hash table with a bigger size when creating
it? and maybe prefill it too.  That way there's a higher chance that
the memory will be returned to the OS when freed...

Message #16 received at 6006 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Dan Nicolaescu <dann <at> gnu.org>, 6006 <at> debbugs.gnu.org
Subject: Re: bug#6006: recent emacs binary size increase by 800KB
Date: Wed, 13 Jul 2011 20:05:26 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

> This said, I don't think it's a real problem since that memory is not
> really wasted (it will be used when Emacs starts to allocate), other
> than on the disk.

Makes sense, so I'm closing this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.