Re: Should we land Lisp reader optimizations?

[Ken Raeburn]

On Jun 20, 2017, at 22:50, michael schuldt <address@hidden> wrote:

> Since the time spent in GC appears so significant, why not disable GC while 
> reading?
> 
> I have not followed all the previous threads so apologies if this question is 
> uninformed

GC doesn’t happen during reading per se, it happens during evaluation of 
expressions and when stopping to wait for user input, but whether it happens at 
those points depends on the amount of storage allocated since the last GC pass. 
 It’s probably possible to come up with GC heuristics that do better than what 
we’ve got now, but there are tradeoffs.  The trick is coming up with the right 
metrics (memory size? CPU time? delay in interactive response? startup speed?) 
and the right use cases to optimize for.  It’d be relatively easy to improve a 
couple of numbers, at the cost of a worse experience in other important cases.  
GC improvement would be a significant research project of its own, one I’m not 
solving this week. :-)

But finding simple ways to avoid doing allocations in the first place is a 
pretty clear win.  Sometimes you get lucky.

My test was parsing each Lisp expression in each of 1447 .elc files (total size 
over 50MB) and looping over all of that 10 times; that means we started with 
something like one GC pass per 16 files processed, on average, which doesn’t 
seem so bad.  (It would be more frequent if we were actually evaluating the 
Lisp expressions that were read.  But I’m only working on the reader code with 
these changes.)  With the various patches, it’s more like one GC pass per 23 
files scanned.

Disabling GC for the duration of reading an entire file probably wouldn’t make 
much difference, then.  This one-GC-per-16-files thing is an average, of 
course; I’d guess the GC probably took place between reading one expression 
from a file and reading the next expression from the same file, but would there 
be any benefit from delaying it until we were between files?

Raising the gc-cons-threshold value so that GC happens less often could also be 
done.  But then you’re likely to get faster memory growth.  It’s something that 
can be considered, but for the purposes of evaluating changes to the Lisp 
reader, I figure one less knob to fiddle with is simplest.

In the scratch branch I’ve been working on, with Stefan’s code to load a saved 
Lisp environment as one big .elc file, I have for now raised the 
gc-cons-threshold value considerably, because the one big .elc file is big 
enough to trigger multiple GC passes, and the entire file has to be read and 
evaluated before interactive use of the Emacs process can start.  But it’s not 
a very good “fix”, as it’ll affect a lot more than startup.  Perhaps I should 
reset it to its normal value at the end of loading the file, but that’d likely 
trigger GC pretty much right away, and I was trying to avoid triggering any GC 
delays before getting to the point of responding to the user’s keyboard input.  
It’ll have to be worked out before we can properly evaluate the performance of 
the big-elc-file approach….

Ken