[Top][All Lists]

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

Re: Skipping unexec via a big .elc file

From: Ken Raeburn
Subject: Re: Skipping unexec via a big .elc file
Date: Mon, 24 Oct 2016 05:40:43 -0400

> On Oct 23, 2016, at 21:07, Stefan Monnier <address@hidden> wrote:
>> That sounds strangely long, as I got less than 2 sec with all the
>> preloaded *.elc files concatenated to a single file, and that's before
>> I made pure-copy a no-op.
>> Another report was that "loadup" with pure-copy short-circuited took
>> less than 0.5 sec.  See
> Hmm... indeed, I got to 0.72s with his patch (on a different, slower
> machine (a Thinkpad X201s, i.e. with a i7 CPU L620 @ 2.00GHz)).
> If I re-add international/characters it goes up a bit to
> 0.96s, but still nowhere near the 3s I got on my big .elc file.
> [ I wonder what makes loading my big file so slow.  ]
> This said, there's still a factor 5-10 to get to "immediate", tho.

I think this came up in the thread Eli referred to, but when I’ve looked at 
startup time in CANNOT_DUMP builds, a couple of things jumped out at me:

* Garbage collection time.  If we’re not trying to dump out as compact as 
possible an image, squeezing out every byte is less important.  Drop all of the 
explicit calls in loadup.el.  Consider raising gc-cons-threshold to the point 
where it doesn’t trigger during loadup; maybe set it back after startup 
completes, or the first time Emacs is idle more than a couple seconds.

* I/O processing time — not the I/O system calls, but the C library processing. 
 Change getc to getc_unlocked in charset.c and lread.c.  (And/or change the 
loading of dumped.elc to read everything into a buffer and execute code from 
the buffer, if that might be faster.)  Mutex locking time is costly on Mac OS 
X, but not exactly free in glibc either.

As I recall, I had startup times under a second without any loadup/dump 
preprocessing with these changes.  (And all the “purecopy” stuff skipped, in a 

Your “dumped.elc” might trigger some of the same issues.  If the eventual idea 
is to stuff the “dumped” data into a char array to link into the final 
installed executable, the second issue is less relevant, though.

Did you check whether actually byte compiling the written file made a 


reply via email to

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