[Top][All Lists]

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

Re: Skipping unexec via a big .elc file

From: Daniel Colascione
Subject: Re: Skipping unexec via a big .elc file
Date: Mon, 24 Oct 2016 07:45:17 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/24/2016 06:35 AM, Eli Zaretskii wrote:
From: Stefan Monnier <address@hidden>
Cc: address@hidden
Date: Mon, 24 Oct 2016 09:04:29 -0400

A small price to pay for the advantages, IMO.

I think some users will run away screaming if Emacs takes a whole second
to start up.

It depends.  If those users, like me, have hundreds of buffers in
their sessions, and use desktop.el to recreate their sessions, they
already wait a few seconds for that.

And I don't expect the result to be 1 sec, that's is a rounded up
value that is already higher than what I saw.

The most important advantage in my view is that the dumping/loading
process becomes very simple and understandable even by people with
minimal knowledge of C subtleties and Emacs internals,

Yes, the benefits are clear, but the cost is pretty steep.

We will have to speed this up, of course.  You didn't expect tossing
unexec to be an easy job, did you?

I think we could live with a 0.2s startup time, but that's already
a pretty high cost:
- 0.2s feels sluggish when you expect "immediate".
- byte-compilation has historically moved from "do it in a single
  session", to "start a separate Emacs session for each file" for good
  reasons.  A 0.2s startup time imposes either a much slower
  byte-compilation, or will compel us to go back to "do it all in
  a single session".

I think you forget parallelism.  We build Emacs with several
compilations running in parallel for a long time.  And byte-compiling
a typical file already takes more than 0.2 sec, sometimes (often?)
significantly more, so I don't see a catastrophe yet.

This would make future maintenance much more robust and reliable, and
also allow more contributors to work on improving, speeding up, and
extending the build process.  The alternatives all require us to
depend on a dwindling handful of people, which is a huge disadvantage
in the long run.

Maybe there's indeed a lot of speed up still waiting there, and by
reducing loading time of .elc files (and/or allowing more laziness there)
we could bring down the 0.96s to 0.2s *and* speed up other uses at the
same time.

That's my hope, yes.  E.g., maybe reading the startup.elc file could
run in another thread?

In any case, I don't think it's right to throw out this idea without
trying very hard to make it work, because the benefits are so clear.

I'm worried that it'll be deemed to "work" at a level of performance much worse than what we have today. My preference would be to keep hammering on this approach and others until we find something with only minimal performance regressions. I don't see the unexec maintenance situation being desperate enough that we need to accept a big performance loss.

reply via email to

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