all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ken Raeburn <raeburn@raeburn.org>
Cc: emacs-devel@gnu.org
Subject: Re: Should we land Lisp reader optimizations?
Date: Tue, 20 Jun 2017 18:25:03 +0300	[thread overview]
Message-ID: <83a852wuk0.fsf@gnu.org> (raw)
In-Reply-To: <DA5054CE-7684-4048-A99B-35AF5132BEBE@raeburn.org> (message from Ken Raeburn on Tue, 20 Jun 2017 06:12:05 -0400)

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Tue, 20 Jun 2017 06:12:05 -0400
> Cc: emacs-devel@gnu.org
> 
> I implemented the benchmark “read all Lisp forms from a set of .elc files previously loaded into buffers” as mentioned in my earlier email.  I used all the .elc files installed by the build, sorted by name.  The test iterated over the whole set of buffers 10 times, after an untimed initial pass.
> 
> With unchanged master sources (63ec338) it took 327s and 920 GC passes.
> 
> I added the change to short-circuit the recursive processing of certain types (#3); 171s.
> 
> I added the change to mutate the placeholder for a cons object instead of doing recursive substitution (#2); 168s.  (I think it did better for me before but maybe it’s specific to dumped.elc.)
> 
> I added the getc_unlocked change (#1), mainly because other patches I was testing updated the same code and I wanted to get numbers quickly without manually updating the patches; 171s.  (The test is reading from buffers, not files, so this is probably just some random run-to-run variability.)
> 
> I then pulled in the change to replace the read_objects list with two hash tables (part of #4); this brought the run time down to 33.4s, despite an increase to 1049 GC passes.
> 
> I added the iteration change (#5) and replaced seen_list with a hash table (other part of #4); no change.  This is expected from #5, and the seen_list change probably requires more #N# values in an expression for it to be significant.
> 
> I added the symbol interning change (#8); the run time is down to 24.6s, with 631 GC passes, and the speedup appears to be mostly from reducing the GC passes.  Overall improvement: 13x reduction in run time, 31% reduction in GC passes.  Remember this is just for parsing the Lisp expressions, not for evaluating or for reading the bits off the disk.

How much faster does it make reading a large .elc file from disk?

In any case, a 13x speedup sounds very impressive, so I think we want
this on master as soon as you can do it.

What do others think?

Thanks.



  reply	other threads:[~2017-06-20 15:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-19 16:58 Should we land Lisp reader optimizations? Eli Zaretskii
2017-06-20  7:08 ` Ken Raeburn
2017-06-20 10:12   ` Ken Raeburn
2017-06-20 15:25     ` Eli Zaretskii [this message]
2017-06-20 15:39       ` Clément Pit-Claudel
2017-06-20 16:06         ` Paul Eggert
2017-06-20 23:12       ` John Wiegley
2017-06-21  2:50         ` michael schuldt
2017-06-21 10:07           ` Ken Raeburn
2017-06-21 17:41           ` Eli Zaretskii
2017-06-22  1:58           ` Richard Stallman
2017-06-22  2:56             ` michael schuldt
2017-06-22  6:25               ` John Wiegley
2017-06-22 13:26           ` Stefan Monnier
2017-06-22  1:57         ` Richard Stallman
2017-06-21  9:46       ` Ken Raeburn
2017-06-21 17:56         ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=83a852wuk0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=raeburn@raeburn.org \
    /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 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.