[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
Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix, Dmitry Gutov, 2013/01/04