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

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>,  Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29095 <at> debbugs.gnu.org
Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Sun, 12 Nov 2017 11:09:14 +0100

> My (tiling) window manager is BSPWM
> <https://github.com/baskerville/bspwm>.  Now let's see what happens
> when
> - `minibuffer-auto-raise' is nil,
> - `x-wait-for-event-timeout' is 0.1 (default):
[...]
> Configuring package minibuffer...done
> Configuring package minibuffer-line...done

Using a tiling window manager plus ‘minibuffer-auto-raise’ plus
‘minibuffer-line’ is about the worst case scenario I could only imagine.
In practice, it means that all visible windows on your desktop may have
to be resized whenever an Emacs message is shown or the contents of the
modeline of the selected Emacs window changes.

> Configuring package recentf...
> Loading ~/.emacs.d/.recentf.el (source)...done
> Configuring package recentf-ext...done
> Configuring package sync-recentf...done
> Configuring package recentf...done (0.135s)
[...]
>
> 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.  Anyway, let's
> disregard it for a moment and assume that it is still fine.  Now let's
> see what happens when

As I never configure any packages I don't understand what you're doing.
For example, I have no idea what configuring packages like "simple" or
"window" does.  But note that recentf.el is the only one of your
"packages" loaded from source and descends into two sub-packages (or
whatever these are) before completing.  And obviously it might look into
the availability of your recent files which could take some time.

> Configuring package window...done
> ---------------------------------------------------------
>  >>> *minibuffer-auto-raise is set to t at this point* <<<
> ---------------------------------------------------------
> Configuring package minibuffer-line...done (0.106s)

Who sets that and what happened to the

Configuring package minibuffer...done

line?

> 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.

Sure.  I suppose your window manager is in heavy troubles.  Why can't
you delay setting ‘minibuffer-auto-raise’ at least until after loading
is complete?

martin

Previous Next

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