Re: Should we land Lisp reader optimizations?

[Ken Raeburn <raeburn@raeburn.org>]

On Jun 20, 2017, at 22:50, michael schuldt <mbschuldt@gmail.com> 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