* 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 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: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
* 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-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
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.