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

[Alexander Shukaev <emacs@Alexander.Shukaev.name>]

On 11/05/2017 12:53 AM, Noam Postavsky wrote:
> Alexander Shukaev <emacs@Alexander.Shukaev.name> writes:
> 
>>> 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.
> 
> Ah, so if I understand correctly, because of the minibuffer-auto-raise
> setting, every time a message is printed Emacs tries to make the frame
> visible, and because of x-wait-for-event-timeout, it waits for 100ms
> each time.  So if you get around ~500 messages during startup, it would
> take about 50 seconds, thus explaining the increase you observed?
> 
> Perhaps the thing to do is simply to disable x-wait-for-event-timeout if
> we end up hitting the timeout.  Under most window managers the frame
> becomes visible much faster than 100ms anyway, as far as I know.

Do you mean to set it to nil as the timeout is hit for the first time?

>> 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.
> 
> Ah yes, I saw that.  It looks like it's not actually a GC issue as such,
> but an (asynchronous) infinite loop that generates a lot of garbage (and
> hence work for the GC).
> 
> https://github.com/ruediger/magit-filenotify/issues/20

Indeed, thanks for rephrasing it.