Re: Preview: portable dumper

[Daniel Colascione]

On 11/28/2016 12:26 PM, John Wiegley wrote:
> > > > > > "DC" == Daniel Colascione <address@hidden> writes:
>
> DC> Yes --- one that *we* control, which frees us from changes to underlying
> DC> systems. Yes, the thing has intimate knowledge of Lisp_Object internals,
> DC> but whoever changes those internals (and these changes are rare) can
> DC> change the dumper too.
>
> Then the difference between .elc and this new -- .eld? -- would be exactly
> what?  Relocation information to speed up load time?
>
> I'm just wondering: if it's strictly a speed gain, then is there any other way
> to achieve it; if it's a functionality gain, what are the advantages over just
> speeding up .elc loading.

The dump can be used as-is without preparation, particularly if it loads 
at its desired base address. Reading an ELC requires lots of parsing, 
interning, and allocation of various sorts. It also prohibits any kind 
of data sharing between differences instances of Emacs on the same 
system, while I expect about a third to half of these dumps to be shared.

It's also possible to dump arbitrarily already-loaded Emacs processes, 
which you don't get with a merged ELC, so that's a functionality difference.

If Lisp layout changes in the future, it's very easy to adjust pdumper 
to match. It's really not a big maintenance burden; read the code.

> Thanks for doing this work, btw!! The value of your exploration is not lost on
> me, since you've now made a concrete alternative for us to consider. If the
> differences in approach are small enough, there's no reason we can't change
> our minds yet again in the future. This is a purely internal matter, after
> all.

Are you rejecting the patch?