unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Removing pure space
Date: Thu, 4 Mar 2021 15:51:30 +0000	[thread overview]
Message-ID: <CAOqdjBfpYJnq8GKcD30M1FPBSDfNEVCDRK1GA78wm2p9NrK=0g@mail.gmail.com> (raw)
In-Reply-To: <CAOqdjBfrbC4+s6LxzAXJxrUW9QuGyizKYfUFyAyLNYEf55tRgg@mail.gmail.com>

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	other threads:[~2021-03-04 15:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04 13:19 Removing pure space Pip Cet
2021-03-04 14:49 ` Stefan Monnier
2021-03-04 14:55   ` Pip Cet
2021-03-04 15:51     ` Pip Cet [this message]
2021-03-04 15:53     ` Stefan Monnier
2021-03-05 20:28 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOqdjBfpYJnq8GKcD30M1FPBSDfNEVCDRK1GA78wm2p9NrK=0g@mail.gmail.com' \
    --to=pipcet@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).