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

[martin rudalics <rudalics@gmx.at>]

 >> 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 didn't miss those and I have no explanation why his minibuffer doesn't
show up  Do you?

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

And we closed them both.

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

IIUC we have three issues here:

(1) Since we always used some sort of waiting, some code that relied on
its presence but (IMHO) should never have been written that way, was
executed as intended by the author.  Bug#25521 was such a case.  I think
this issue should be fixed by supplying the entire available information
(like the expected frame size or the asked for name) at the time the
frame is created.  If anything changes later, we'll inform about that
change in due time.

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

(3) Sometimes for a frame it may take forever to become visible.  That's
the case you cited earlier with a frame that is expected to pop up on a
different workspace.

In some sense all of these are problems we have not completely resolved
for at least one sort of timeout a user chooses.

martin