GNU bug report logs - #29095
Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s

Previous Next

Full log

Message #22 received at 29095 <at> debbugs.gnu.org (full text, mbox):

From: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29095 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481'
 merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Sun, 5 Nov 2017 00:28:15 +0100

> What confuses me though, is how a 100ms delay is adding ~50s to your
> starup time?!  Or are you just creating 500 frames on startup?

Hah, of course not.  So I took some additional time to investigate where 
this comes from and in turned out to be very simple:

(setq-default minibuffer-auto-raise t)

causes this.  I think this needs to be addressed.  Either by documenting 
this side effect or finding a better solution.

>> As the output from the build kept arriving to the *compilation*
>> buffer, I kept getting "Garbage collecting...done" spam (at random
>> times), stuttering the output coming into *compilation* buffer.  You
>> don't have to explain to me here anything about GC, I am well aware of
>> all of these issues.
> 
> Just to clarify, you have garbage-collection-messages set to non-nil on
> purpose?

On purpose.  I want to know why Emacs stutters, so I monitor this in 
order to come up with better GC parameters for my workflows.  Anyway, I 
figured out why this GC issue was happening.  It's a bug with 
`magit-filenotify' package, which I've already reported and found 
workaround for.  So apart from my concerns about `minibuffer-auto-raise' 
and `x-wait-for-event-timeout', looks good so far.

Regards,
Alexander

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.