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

[Noam Postavsky]

Alexander Shukaev <emacs@Alexander.Shukaev.name> writes:

> Hi guys,
>
> On 11/09/2017 07:12 PM, martin rudalics wrote:
>> (2) Apparently sometimes the window system / manager does not inform us
>> that a frame has become visible although the frame apparently has become
>> visible.  If I'm not mistaken that's what Alexander sees (or is not able
>> to see).
>
> Apologies for the delay, I was off to another town for a couple of
> days. So let me provide some more details of what's going on and what
> is the use case.  It's actually nothing special, and that's why I'm
> also confused how nobody noticed that before.  All I do is just start
> new Emacs instance.  My (tiling) window manager is BSPWM
> <https://github.com/baskerville/bspwm>.

Do you have the Emacs instance showing up in a different virtual
desktop, or somehow prevent it from becoming visible immediately?  It
could be that this window manager somehow prevents Emacs from getting
the expected events to udpate frame visibility correctly.

> Notice how configuring of package `recentf' suddenly appears to stand
> out and it contains that single 100 ms delay.  Curiously no matter how
> many times I restart Emacs, it's always `recentf' that gets this
> delay. I have no idea why but it's for sure related.

I suppose either recentf and/or your configuration of it are doing
something which takes a lot of time (e.g., reading from disk).

> Look how as soon as `minibuffer-auto-raise' is set to t,
> configurations of all subsequent packages obviously get delayed by 100
> ms each.  This is most probably caused by the messages being written
> to minibuffer.

Right.

> On 11/09/2017 11:09 PM, Alexander Shukaev wrote:
>> - `x-wait-for-event-timeout' is nil, there are no additional delays at all.
>
> Ha, I take this last phrase back.  It's actually getting interesting,
> in fact, when `x-wait-for-event-timeout' is nil:
>
> Configuring package recentf...done (0.365s)
>
> but with `x-wait-for-event-timeout' being 0.1:
>
> Configuring package recentf...done (0.131s)
>
> it's back to lower again.  Whaaat?

Is this consistent, or perhaps just a fluke?