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
martin rudalics <rudalics <at> gmx.at> 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.
This bug report was last modified 6 years and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.