Re: reducing emacs size by more frequent garbage-collect in loadup.el

[Ken Raeburn]

On Jul 26, 2009, at 14:57, Dan Nicolaescu wrote:
> > Another way to win similar improvements might be to lower the value  
> > of
> > gc-cons-threshold and friends during loadup.el.
>
> This sounds like it's a bit more complicated...

It should just take a 'let' binding around most of the interesting  
parts of loadup.el.  (Or setq, if you don't mind not recovering the  
default value set in C code.)  So it means reindenting, but not  
dropping in lots of explicit GC calls.  It also means GC will run more  
frequently during loads, instead of in between.  There's also a lower  
limit, below which gc-cons-threshold will be reset during GC.  So the  
impact in time and space may be quite different.

I'd also be surprised if there didn't turn out to be one or two  
strategic places in loadup.el where you could insert GC calls and get  
back quite a portion of that 2%.  In the early parts of the process,  
where most of the garbage slots generated are likely to be filled by  
files loaded later, doing extra GC passes just seems like wasted work.

On the other hand, I would expect that 2% savings in file size is  
mainly just saving disk space; the extra memory in the larger image  
should be reused fairly soon after starting up the dumped Emacs as it  
allocates and GCs, shouldn't it, where the smaller Emacs will just  
have to allocate the space from the OS a bit sooner?  Is there any  
impact on run-time memory use?  At a difference of 132K, maybe it  
would take a little while for the smaller one to catch up, but how  
much does it take -- a few editing or programming modes to be loaded?   
Running font-lock over a large C file?

I just did a quick experiment on my Mac; let-binding gc-cons-threshold  
to its minimum value of 10000 for the duration of the loads and other  
work cut 80K of the data-section size in the dumped image, which is  
less than 1%; by the time the processes started up, created X11  
windows, and loaded my .emacs, process memory size differed by only  
32K, which suggests to me that most of that space saved in the dumped  
image was needed soon after startup anyways, though not all of it.

Ken