Re: Skipping unexec via a big .elc file

[joakim@verona.se]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Apr 3, 2017, at 15:14, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Ken Raeburn <raeburn@raeburn.org>
>>> Date: Mon, 3 Apr 2017 14:35:16 -0400
>>> Cc: emacs-devel@gnu.org
>>> 
>>> Despite a few little speed-ups, I’ve got my doubts as to whether it’s going to be fast enough.
>> 
>> I published my preliminary timings in these 2 messages:
>> 
>>  http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00923.html>  http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00959.html
>
> Yes, I got some speedups, but I didn’t get it as fast as I was hoping.  Some of my changes since your second message above might’ve improved the numbers a little, but some (like loading the doc pointers at startup, and I think “uniquify” is going to need to be loaded at startup too because it attaches advice to “rename-buffer” which we can’t save properly) may slow it a little too.
>
> I was aiming for a startup time under a tenth of a second, and didn’t get there, though there were a couple of additional things that could be tried, with some effort.  I’m not sure a startup time of nearly a fifth of a second will feel for people.  If they start Emacs once as part of logging in, it probably won’t be an issue.  If they start it every time they want to edit a file, it may be annoying to have the startup time increased by even 0.15s.

In my case I mostly use long-running sessions, so slow emacs startup
isn't so bad for me. Most of the boot time seem to happen in 3rd party
libs anyway.

But on the other hand I think there is a valid use case for using Emacs
for things like batch processing, web servers and such. And in those
cases startup time matters. Again otoh, you might want to use
emacsclient together with a long running emacs in those cases. But I'm
not really using emacs for that sort of thing so one should listen to
the people actually doing it primarily.

>
> Still, I suppose we can let people try it out, and find out what they think.  Then we can decide if it’s good enough, if further speedup measures are worth exploring, or if it’s a dead end.
>
> Ken
-- 
Joakim Verona
joakim@verona.se