bug#6006: recent emacs binary size increase by 800KB

bug#6006: recent emacs binary size increase by 800KB

[Dan Nicolaescu]

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@iro.umontreal.ca>

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

bug#6006: recent emacs binary size increase by 800KB

[Stefan Monnier]

> 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

bug#6006: recent emacs binary size increase by 800KB

[Dan Nicolaescu]

Stefan Monnier <monnier@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...

bug#6006: recent emacs binary size increase by 800KB

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@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/