emacs-devel
[Top][All Lists]
Advanced

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

Re: Removing pure space


From: Pip Cet
Subject: Re: Removing pure space
Date: Thu, 4 Mar 2021 15:51:30 +0000

On Thu, Mar 4, 2021 at 2:55 PM Pip Cet <pipcet@gmail.com> wrote:
> On Thu, Mar 4, 2021 at 2:49 PM Stefan Monnier <monnier@iro.umontreal.ca> 
> wrote:
> > > I have not been able to measure any performance changes with this
> > > patch applied, but unfortunately I'm currently on a system unsuitable
> > > for running reliable benchmarks. If this is a concern, any help
> > > measuring the performance impact more accurately would be appreciated.
> >
> > The main expected benefit from the purespace is that the GC doesn't need
> > to look at it, so the GC should be faster because it looks at a smaller
> > part of the heap.
>
> With pdumper, I don't think that's true anymore. There are three Lisp
> objects for which PURE_P returns true: the empty vector, unibyte
> string, and multibyte string.
>
> In fact, if anything, it'll be slower because of the extra overhead of
> the PURE_P checks...
>
> > So I think a good micro-benchmark which should expose the worst-case
> > impact of removing the purespace would be to compare the time taken to
> > perform GC (I think the effect should be most visible right at startup
> > since the more packages and stuff you have loaded, the smaller the
> > proportion of the heap kept in purespace).
>
> So you're saying I should build with unexec, then run something like:
>
> "time ./emacs --batch --eval '(dotimes (i 10000) (garbage-collect))'
>
> ? Because I don't really think that benchmark makes sense with pdumper...

2590983 pure bytes used

Okay. I've just sacrificed several small animals (one of them kept
screaming DO NOT EDIT! GENERATED AUTOMATICALLY!) in order to build
emacs with unexec one final time. Two final times, in fact, with and
without my patch.

And here I was going to gloat about how there's no measurable
difference, but there is. It's faster by about a millisecond per
(garbage-collect) call, or about 30% of the time that loop takes.

Again, though, that's only compared to unexec, which hasn't built
since Paul merged my eager hash table rehashing patch quite some time
ago, and isn't trivial to build even with that fixed.

Pip



reply via email to

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