[Top][All Lists]

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

Re: Should we land Lisp reader optimizations?

From: Ken Raeburn
Subject: Re: Should we land Lisp reader optimizations?
Date: Wed, 21 Jun 2017 05:46:11 -0400

On Jun 20, 2017, at 11:25, Eli Zaretskii <address@hidden> wrote:

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

I tried a couple of file-loading tests:

1) Loading several Gnus nn* files, several progmodes, and a few others, then 
unloading them all, in a loop 50 times.  Run time dropped from 14.6s to 13.3s, 
about a 9% drop; GCs went from 176 to 136.  The getc_unlocked and 
symbol-interning changes appear to have had the biggest effect in this case.

2) Loading ja-dic.elc, the biggest .elc file in my build tree, 100 times.  Run 
time went from 14.3s to 9.3s, about a 35% drop; GCs went from 200 to 101.  I 
didn’t break this one down by individual code changes.

I don’t think anything in the tree is likely to show the high degree of object 
sharing and the huge number of shared objects being tracked at one time that 
dumped.elc does.

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

Okay, looks like people are in favor, so I’ll try to get the more effective 
smaller patches pulled in this week.  The less helpful ones I’ll keep on my 
scratch branch for now.  And I’ve still got the #N# symbol sharing and 
file-reading specialization changes to evaluate with the master branch.


reply via email to

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