Re: Finding the dump

[Daniel Colascione]

> On 1/28/19 8:02 AM, Daniel Colascione wrote:
>> The overhead of opening a file in libexec is negligible.
>
> It's not just opening the file; it's reading the file and eagerly
> converting its data to internal format.

Data conversion is slow, which is why pdumper doesn't do it. The dump is a
memory image, not an elc file. We do need to relocate the dump in order to
adjust it for ASLR, but any dumper approach needs to do that, or disable
ASLR.

I experimented with a non-relocatable, relocation-less mode for pdumper
--- just mark Emacs as non-PIC and embed the dump in the emacs data
segment, so it's located at a constant address in memory on each run ---
but it turns out that relocation is so fast, only 1-2ms, that it's really
not worth the trouble. And from a security POV, we shouldn't be
encouraging people to disable ASLR.

I'm not sure what your proposal is, exactly, or how it would differ from
this non-PIC pdumper mode.

> Not everybody cares as much about startup latency as I do, and I can
> understand it if the issue does not seem that important to others. But
> on my platform, Emacs master's startup time is more than twice as long
> than (say) Python 3's, and I'd like to see Emacs catching up rather than
> falling further behind.

One option is to do pdumper relocations on-demand, in a SIGSEGV handler. I
actually implemented this approach, and it works fine, but because we have
a dumb stop-the-world non-generational GC, we ended up paging in most of
the dump on the first GC anyway, so doing relocations on demand doesn't
actually help. If we had a generational GC, we could avoid paging in most
of the dump, speeding both startup and steady-state performance.

But look at it from a different POV: we can make emacs -Q faster, but the
performance of emacs -Q doesn't matter for most users. Most user-visible
startup latency comes from user customization. The single biggest
improvement we can make to observed startup time for typical users is to
use pdumper to automatically checkpoint Emacs after user customization
and, on subsequent startups, skip all the ~/.emacs work. I explicitly
designed pdumper to make this use case possible. This change, along with
automatic .elc maintenance, will do more for real-world Emacs performance
than GC tweaks or incremental improvements to pdumper load performance.