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

[Alexander Shukaev]

On 11/01/2017 02:31 AM, Noam Postavsky wrote:
> tags 29095 + moreinfo
> quit
>
> Alexander Shukaev <emacs@Alexander.Shukaev.name> writes:
>
> > Hi,
> >
> > Decided to try pretest of 26.0.90 and immediately discovered that it
> > is slower than, for example,
> > 'e7f65187580342171dd9ad32e570c50c96badb13' which I used before.  In
> > particular, thanks to a couple of hours of bisecting, I found that the
> > '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs
> > configuration loading time from 9 s to 60 s, which is unacceptable.
>
> I know what you mean by "which is unacceptable", but somehow on first
> reading it strikes me as rather bossy and entitled.

Apologies, didn't want it to sound like that.  Was truly frustrated by 
the experience.  The problem was also that until the very last moment I 
refused to believe that I would really hit something like this on a 
"pretest" tag from the 'master' branch.  I did OS upgrade recently as 
well, so I first started to profile my SSD RAID for possible performance 
degradation (as Emacs reads lots of file at startup) and look for any 
issues I could have introduced in the custom Linux kernel.  I rolled 
back Emacs only as the very last resort and to my (unpleasant) surprise 
that was the culprit.

> > I have no idea how this made it's way to the 'master' branch.
>
> This sentence kind of suggests you think that the 'master' branch is
> supposed to be the most stable, but it's rather emacs-26 (being the
> release branch) which is intended to be more stable.  Note that
> e7f6518758 which you said is okay, is contained in both emacs-26 and
> master.

As my original findings (namely merge commit from the 'emacs-26' branch) 
demonstrated, there is no stable branch at the moment as the faulty 
commit is now present in both.  In fact, the 'emacs-26' was merged to 
master (and not vice versa), so it's the issue that came from what you 
call a "stable" branch.  This is another surprise for me.

> > 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
> > core has really been changed and potentially broken.  This needs
> > investigation; let me know what can I do for you guys from my side.
> > Thanks.
>
> I see two possible directions to investigate:
>
> 1. You bisect farther along the emacs-26 branch, as a merge commit
> collects a whole bunch of changes, and so doesn't really narrow things
> down at all.

And that's what I just finished doing, voilà:

e1f6e3127a292e6ba66d27c49ddda4fe949569f5
Author:     Noam Postavsky
AuthorDate: Wed Aug 30 23:12:22 2017 -0400
Commit:     Noam Postavsky
CommitDate: Fri Sep 29 18:40:06 2017 -0400

And yes, of course, as soon as I found this by spending a couple of 
hours more doing bisecting, I did immediately set 
`x-wait-for-event-timeout' to nil and the startup problem was gone. 
However, I'm still gravely concerned that such defaults (100 ms GUI 
delays) suddenly get added (whatever the reason for this new option was) 
and affect both branches.

Now, that was only the first part.  I'm still going to continue 
bisecting further why there are new obvious issues with garbage 
collecting (as those seem to be somewhere deeper in the 'emacs-26' 
branch).  For instance, while I was doing bisecting for the above 
finding, I kept rebuilding the Emacs package from scratch in a clean 
environment and I did so using `compilation-mode'.  As the output from 
the build kept arriving to the *compilation* buffer, I kept getting 
"Garbage collecting...done" spam (at random times), stuttering the 
output coming into *compilation* buffer.  You don't have to explain to 
me here anything about GC, I am well aware of all of these issues.  The 
point is that such frequent GC spam and stuttering of output did not 
happen before and I didn't change GC settings.  Now, this is not even 
the most irritating about this, it's rather that frequently it happens 
so that "Garbage collecting...done" would just hang out there and the 
build output would stop completely, in fact, the whole Emacs is blocked 
waiting for something to happen from GC but either that GC either hangs 
itself or it takes too long that I lose my patience.  What I had to do 
in such cases, is simply spam <C-g> just so that Emacs aborts those 
faulty GC attempts, unblocks, and I can finally see my build output 
being aggressively flushed into the *compilation* buffer (as the build 
is in reality already much further away from the point where the output 
stopped).

Regards,
Alexander