emacs-devel
[Top][All Lists]
Advanced

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

Re: Skipping unexec via a big .elc file (was: When should ralloc.c be us


From: Eli Zaretskii
Subject: Re: Skipping unexec via a big .elc file (was: When should ralloc.c be used?)
Date: Sun, 23 Oct 2016 20:34:38 +0300

> From: Stefan Monnier <address@hidden>
> Date: Sun, 23 Oct 2016 12:44:33 -0400
> 
> >> If someone wants to do that, great. I'd rather spend my own limited
> >> cycles on fixing the main problem, which is unexec.
> > I thought we agreed to get rid of unexec by loading a single .elc file
> > at startup of Emacs, and remove the distinction between temacs and
> > Emacs altogether.  Is that what you'd like to work on?
> 
> FWIW, I just did a quick experiment with the patch below which dumps the
> state of Emacs's obarray after loadup.el into a big "dumped.elc" file.
> Not sure if such an approach could work, but in any case I expect that
> a working .elc file should likely be of comparable size.
> 
> The result is a .elc file of 3.3MB which seems reasonable.
> When I try to load it, tho, I get:
> 
>     % time src/emacs -Q --batch -l dumped.elc -f kill-emacs
>     src/emacs -Q --batch -l dumped.elc -f kill-emacs  3.50s user 0.00s system 
> 99% cpu 3.506 total
>     % 
> 
> And that's with a warm cache on "i3-4170 CPU @ 3.70GHz" (my first, and
> still only, CPU that goes beyond 3GHz).
> 
> So even if there might be ways to speed this up, it doesn't look
> too promising.

That sounds strangely long, as I got less than 2 sec with all the
preloaded *.elc files concatenated to a single file, and that's before
I made pure-copy a no-op.

Another report was that "loadup" with pure-copy short-circuited took
less than 0.5 sec.  See

  https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html

Was your Emacs an optimized build?



reply via email to

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