[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
CANNOT_DUMP build.)
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
difference?
Ken
- Re: Skipping unexec via a big .elc file, (continued)
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/25
- Re: Skipping unexec via a big .elc file, Perry E. Metzger, 2016/10/25
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2016/10/25
- Re: Skipping unexec via a big .elc file, Perry E. Metzger, 2016/10/25
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2016/10/24
- Re: Skipping unexec via a big .elc file, Perry E. Metzger, 2016/10/25
- Re: Skipping unexec via a big .elc file,
Ken Raeburn <=
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/24
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/25
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/25
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/27
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2016/10/30
- Re: Skipping unexec via a big .elc file, Simon Leinen, 2016/10/30
- Re: Skipping unexec via a big .elc file, Daniel Colascione, 2016/10/30
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2016/10/31
- Re: Skipping unexec via a big .elc file, Lars Brinkhoff, 2016/10/24
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2016/10/24