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
On 11/01/2017 02:31 AM, Noam Postavsky wrote:
> tags 29095 + moreinfo
> quit
>
> Alexander Shukaev <emacs <at> 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
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.