Re: Skipping unexec via a big .elc file

[Stefan Monnier]

>> At startup, we'll load the dump file and walk the relocations, fixing up
>> all the embedded addresses to account for the new process's different
>> address space.
> Why do you think this will have better performance that reading a
> single .elc file at startup?  It's still mainly file I/O and
> processing of the file's contents, just like with byte-compiled files.

I guess it depends if we can get lread.c to be bound by file-I/O.
Currently, it's significantly slower.

It's clear on the surface that lread.c has more work to do than an ideal
"portable undumper":
- the PU just has to find all pointers and increment them by
  a fixed offset (it could do so either by a GC-like traversal, or by
  consulting an auxiliary precomputed table of addresses stored alongside
  the dump state)
- lread.c has to check every byte for lexing/parsing, it has to call the
  memory allocator for every object, tie the knots for cyclic objects,
  `intern` the symbols, decode the \ in strings, ...

The jury is still out whether this extra work can be implemented
efficiently enough.  There are other differences which can impact the
performance (e.g. the size of the "dump" is likely different in the two
cases, so the amount of I/O is affected) and the desirability (speeding
up loading of .elc would benefit other cases as well, we could generate
a generic dump.elc rather than have it be OS-specific, ...)


        Stefan