emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix


From: Stefan Monnier
Subject: Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
Date: Fri, 04 Jan 2013 13:10:00 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> The arguments that killed purespace for us were (1) most users
> (including most of those who argued for keeping purespace :-) are in
> one-xemacs-process-per-machine workflows, and (2) in theory modern
> virtual memory management by OSes (we were specifically influenced by
> Linux and Windows) should produce most of the benefits of purespace
> anyway, since the dumped code contains only a few writable objects,
> and those tend to be clumped on a very few pages per file, such that
> the potentially written pages might be measured in 100s of KB out of
> the 3-5 MB (at that time) of XEmacs memory.
> I'm not sure I believe (2), though.

I also doubt 2 is true, unless XEmacs's object layout has been changed
to move the markbit out of their objects.  All live objects's markbits
get written during a GC (except for purespace, of course), regardless of
the object being read-only.

But I don't see this sharing as tremendously important: we're talking
about a purespace of about 2MB, for a process whose code size is larger
and whose minimal runtime size is also a good bit larger.
Negligible?  I don't know!  but not terribly important.

OTOH the GC time at start up is reduced by almost a factor 3 (the Lisp
heap size of "emacs -Q" is about 1MB, whereas it'd be around 3MB if it
weren't for the purespace).  On the third hand, this Gnus process has
a Lisp heap size of about 100MB, so the purespace makes virtually no
difference (we'd need a generational GC, instead).



        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]