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

[Noam Postavsky]

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.

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

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

2. You bisect and/or profile your Emacs configuration to see what part
is taking so long.  Ideally post something that can reproduce the
slowness starting from 'emacs -Q'.  Currently, your report pretty much
just says "*something* is slow", which nobody can really do anything
with.