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 #64 received at 29095 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>
Cc: 29095 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481'
 merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Thu, 09 Nov 2017 19:53:13 -0500

Alexander Shukaev <emacs <at> 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?

Previous Next

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