|
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 all.
Are you rejecting the patch?
[Prev in Thread] | Current Thread | [Next in Thread] |