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

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

[Dmitry Gutov]

I wonder, wouldn't it still make sense to purecopy the form, just not
the list wrapping it?

Glenn Morris <rgm@gnu.org> writes:
> ------------------------------------------------------------
> revno: 111116
> fixes bug: http://debbugs.gnu.org/13331
> committer: Glenn Morris <rgm@gnu.org>
> branch nick: emacs-24
> timestamp: Wed 2013-01-02 16:50:35 -0800
> message:
>   eval-after-load fix
>   
>   * lisp/subr.el (eval-after-load): Don't purecopy the form, so that it
>   can be nconc'd later on; reverts 2009-11-11 change.
> modified:
>   lisp/ChangeLog
>   lisp/subr.el
> === modified file 'lisp/ChangeLog'
> --- a/lisp/ChangeLog	2013-01-03 00:43:46 +0000
> +++ b/lisp/ChangeLog	2013-01-03 00:50:35 +0000
> @@ -1,5 +1,8 @@
>  2013-01-03  Glenn Morris  <rgm@gnu.org>
>  
> +	* subr.el (eval-after-load): Don't purecopy the form, so that it
> +	can be nconc'd later on; reverts 2009-11-11 change.  (Bug#13331)
> +
>  	* emacs-lisp/byte-run.el (defun): Place cl declarations
>  	after any interactive spec.  (Bug#13265)
>  
>
> === modified file 'lisp/subr.el'
> --- a/lisp/subr.el	2013-01-01 09:11:05 +0000
> +++ b/lisp/subr.el	2013-01-03 00:50:35 +0000
> @@ -1877,7 +1877,7 @@
>  		 ,form)))
>        ;; Add FORM to the element unless it's already there.
>        (unless (member form (cdr elt))
> -	(nconc elt (purecopy (list form)))))))
> +	(nconc elt (list form))))))
>  
>  (defvar after-load-functions nil
>    "Special hook run after loading a file.

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

[Glenn Morris]

Dmitry Gutov wrote:

> I wonder, wouldn't it still make sense to purecopy the form, just not
> the list wrapping it?

Maybe. (Personally, I doubt any of these purecopy calls have any
non-negligible effect.) Feel feel to tweak it in trunk.

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

[Stephen J. Turnbull]

Glenn Morris writes:

 > Maybe. (Personally, I doubt any of these purecopy calls have any
 > non-negligible effect.)

FWIW, XEmacs did away with purespace ages ago with no complaints from
anybody.  (We still have `purecopy' for API compatibility with Emacs,
but it's a no-op now.)

That's damning with faint praise, of course, but it's a data point.

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

[Dmitry Gutov]

On 03.01.2013 7:27, Stephen J. Turnbull wrote:
> Glenn Morris writes:
>
>   > Maybe. (Personally, I doubt any of these purecopy calls have any
>   > non-negligible effect.)
>
> FWIW, XEmacs did away with purespace ages ago with no complaints from
> anybody.  (We still have `purecopy' for API compatibility with Emacs,
> but it's a no-op now.)
>
> That's damning with faint praise, of course, but it's a data point.

Is it really faint, though? If the removal of purespace brought no 
slowdown, why keep it in GNU Emacs?

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

[Stephen J. Turnbull]

Dmitry Gutov writes:
 > On 03.01.2013 7:27, Stephen J. Turnbull wrote:
 > > Glenn Morris writes:
 > >
 > >   > Maybe. (Personally, I doubt any of these purecopy calls have any
 > >   > non-negligible effect.)
 > >
 > > FWIW, XEmacs did away with purespace ages ago with no complaints from
 > > anybody.  (We still have `purecopy' for API compatibility with Emacs,
 > > but it's a no-op now.)
 > >
 > > That's damning with faint praise, of course, but it's a data point.
 > 
 > Is it really faint, though?

Yes, it is faint.  I have no numbers on comparative performance in
speed or size, and I wouldn't be surprised if it increases total
memory usage for some multi-xemacs-process cases (see Andreas's post).

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.

Steve

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

[Stefan Monnier]

> 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]

On 04.01.2013 22:10, Stefan Monnier wrote:
>> 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).

So, it seems to me the main beneficiary of purespace should be code that 
launches short-lived Emacs subprocesses, like John Wiegley's emacs-async 
package.

I wonder if we can get some numbers on its performance with and without 
purespace.

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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I also doubt 2 is true, unless XEmacs's object layout has been changed
 > to move the markbit out of their objects.

It hasn't.  OTOH, object layout has been tweaked a bit, and our GC has
radically changed, though not by moving the markbits.  Object layout
changes were also part of the rationale for eliminating purespace
ISTR.

Since you guys did a pretty radical change without eliminating
purespace, I don't see a real benefit getting rid of it now.

Steve

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

[Dmitry Gutov]

On 03.01.2013 5:38, Glenn Morris wrote:
> Dmitry Gutov wrote:
>
>> I wonder, wouldn't it still make sense to purecopy the form, just not
>> the list wrapping it?
>
> Maybe. (Personally, I doubt any of these purecopy calls have any
> non-negligible effect.) Feel feel to tweak it in trunk.

I'd maybe tweak it if I knew what to benchmark for.

IIUC, adding stuff to purespace makes GC's job simpler, as it doesn't 
have to keep track of references to those objects. Is that the only 
supposed benefit?

So, I would benchmark it with a simple loop that creates GC pressure, right?

I don't need to measure the time the dumping during the build takes, for 
example?

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

[Andreas Schwab]

Dmitry Gutov <dgutov@yandex.ru> writes:

> IIUC, adding stuff to purespace makes GC's job simpler, as it doesn't have
> to keep track of references to those objects. Is that the only supposed
> benefit?

The main advantage of the pure space is that it is a compact read-only
space which can be shared by the OS between all emacs processes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[joakim]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> IIUC, adding stuff to purespace makes GC's job simpler, as it doesn't have
>> to keep track of references to those objects. Is that the only supposed
>> benefit?
>
> The main advantage of the pure space is that it is a compact read-only
> space which can be shared by the OS between all emacs processes.

My first thought when I read this was that this is not so important
these days. Then it occured to me that maybe the opposite is true:
several newer Emacs frameworks rely on spawning new emacs processes.
>
> Andreas.

-- 
Joakim Verona