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

From: Noam Postavsky <[email-masked]>
Date: Thu, 09 Nov 2017 08:20:34 -0500

martin rudalics <[email-masked]> writes:

>>> But as long as a user doesn't switch to that workspace she won't observe
>>> that making a new frame is slower. So I seem to be missing something.
>>
>> She can observe it indirectly via lisp code.
>
> But Alexander said
>
>  Furthermore, other operations like navigation across windows or
>  performing an incremental search are also noticeably slower, i.e. they
>  stutter annoyingly, and from what I see is a result of extensive GC
>  spam which did not occur in previous versions.  Looks like something
>
> so he must have had a direct, immediate experience.

Ah, perhaps you missed it, that's actually a separate problem.  See
latter halves of #22 & #25.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#22
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#25

>> I would still like to phase it out.  Maybe we could set the default to
>> nil for Emacs 27?
>
> I'd set the default to nil for the release.  Did we have any open bugs
> when you added that option?

As far as I know, the only cases of trouble due to not waiting were
Bug#25521 and Bug#25511.

I would note that the dependency on frame visibility is somewhat
non-obvious in both cases (the dependency in the #25521 case is now
eliminated by changing select-frame-by-name).  So talking about
visibility in etc/PROBLEMS is not necessarily of much use.