[Top][All Lists]

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

Re: Preview: portable dumper

From: Eli Zaretskii
Subject: Re: Preview: portable dumper
Date: Tue, 29 Nov 2016 20:23:27 +0200

> From: John Wiegley <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Tue, 29 Nov 2016 10:03:01 -0800
> >>>>> "EZ" == Eli Zaretskii <address@hidden> writes:
> EZ> However, a dumper that we control by manually telling it what to dum and
> EZ> what not doesn't have to do that. IMO, that's just something that doesn't
> EZ> need to exist in the brave new unexec-free world. (Note that the "one huge
> EZ> .elc file" method has this built-in.)
> I'd still like to see research into the "one huge .elc file" method, for the
> obvious benefits you listed.

Stefan and Ken made some good progress.  IMO, we should actively
continue pursuing that goal.

> As far as I understand, the only difference between the portable
> dumper, and one-huge-.elc, is efficiency. Given infinite resources,
> the .elc method is much to be preferred, since everything we need
> "falls out" from existing design.

Any memory dumper will always be more efficient than loading .elc.
The challenge is to make the difference smaller than the annoyance
level of the users.  Since initial testing already produces load times
below 0.5 sec, I don't see why further optimizations won't deliver
enough speedup to make it fast enough.

reply via email to

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