[Top][All Lists]

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

Re: Preview: portable dumper

From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Mon, 28 Nov 2016 12:31:39 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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

Are you rejecting the patch?

reply via email to

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