* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
[not found] <E1TqZR5-0007qr-6Z@vcs.savannah.gnu.org>
@ 2013-01-03 1:27 ` Dmitry Gutov
2013-01-03 1:38 ` Glenn Morris
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry Gutov @ 2013-01-03 1:27 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-03 1:27 ` /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix Dmitry Gutov
@ 2013-01-03 1:38 ` Glenn Morris
2013-01-03 3:27 ` Stephen J. Turnbull
2013-01-04 5:32 ` Dmitry Gutov
0 siblings, 2 replies; 11+ messages in thread
From: Glenn Morris @ 2013-01-03 1:38 UTC (permalink / raw
To: Dmitry Gutov; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-03 1:38 ` Glenn Morris
@ 2013-01-03 3:27 ` Stephen J. Turnbull
2013-01-04 5:34 ` Dmitry Gutov
2013-01-04 5:32 ` Dmitry Gutov
1 sibling, 1 reply; 11+ messages in thread
From: Stephen J. Turnbull @ 2013-01-03 3:27 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-03 1:38 ` Glenn Morris
2013-01-03 3:27 ` Stephen J. Turnbull
@ 2013-01-04 5:32 ` Dmitry Gutov
2013-01-04 9:39 ` Andreas Schwab
1 sibling, 1 reply; 11+ messages in thread
From: Dmitry Gutov @ 2013-01-04 5:32 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-03 3:27 ` Stephen J. Turnbull
@ 2013-01-04 5:34 ` Dmitry Gutov
2013-01-04 10:58 ` Stephen J. Turnbull
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry Gutov @ 2013-01-04 5:34 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 5:32 ` Dmitry Gutov
@ 2013-01-04 9:39 ` Andreas Schwab
2013-01-04 10:41 ` joakim
0 siblings, 1 reply; 11+ messages in thread
From: Andreas Schwab @ 2013-01-04 9:39 UTC (permalink / raw
To: Dmitry Gutov; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 9:39 ` Andreas Schwab
@ 2013-01-04 10:41 ` joakim
0 siblings, 0 replies; 11+ messages in thread
From: joakim @ 2013-01-04 10:41 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 5:34 ` Dmitry Gutov
@ 2013-01-04 10:58 ` Stephen J. Turnbull
2013-01-04 18:10 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Stephen J. Turnbull @ 2013-01-04 10:58 UTC (permalink / raw
To: Dmitry Gutov; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 10:58 ` Stephen J. Turnbull
@ 2013-01-04 18:10 ` Stefan Monnier
2013-01-04 22:32 ` Dmitry Gutov
2013-01-05 2:54 ` Stephen J. Turnbull
0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2013-01-04 18:10 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: emacs-devel, Dmitry Gutov
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 18:10 ` Stefan Monnier
@ 2013-01-04 22:32 ` Dmitry Gutov
2013-01-05 2:54 ` Stephen J. Turnbull
1 sibling, 0 replies; 11+ messages in thread
From: Dmitry Gutov @ 2013-01-04 22:32 UTC (permalink / raw
To: Stefan Monnier; +Cc: Stephen J. Turnbull, emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix
2013-01-04 18:10 ` Stefan Monnier
2013-01-04 22:32 ` Dmitry Gutov
@ 2013-01-05 2:54 ` Stephen J. Turnbull
1 sibling, 0 replies; 11+ messages in thread
From: Stephen J. Turnbull @ 2013-01-05 2:54 UTC (permalink / raw
To: Stefan Monnier; +Cc: Dmitry Gutov, emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-01-05 2:54 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1TqZR5-0007qr-6Z@vcs.savannah.gnu.org>
2013-01-03 1:27 ` /srv/bzr/emacs/emacs-24 r111116: eval-after-load fix Dmitry Gutov
2013-01-03 1:38 ` Glenn Morris
2013-01-03 3:27 ` Stephen J. Turnbull
2013-01-04 5:34 ` Dmitry Gutov
2013-01-04 10:58 ` Stephen J. Turnbull
2013-01-04 18:10 ` Stefan Monnier
2013-01-04 22:32 ` Dmitry Gutov
2013-01-05 2:54 ` Stephen J. Turnbull
2013-01-04 5:32 ` Dmitry Gutov
2013-01-04 9:39 ` Andreas Schwab
2013-01-04 10:41 ` joakim
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.