[Top][All Lists]

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

Re: Skipping unexec via a big .elc file

From: joakim
Subject: Re: Skipping unexec via a big .elc file
Date: Tue, 04 Apr 2017 12:27:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Ken Raeburn <address@hidden> writes:

> On Apr 3, 2017, at 15:14, Eli Zaretskii <address@hidden> wrote:
>>> From: Ken Raeburn <address@hidden>
>>> Date: Mon, 3 Apr 2017 14:35:16 -0400
>>> Cc: address@hidden
>>> 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

reply via email to

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