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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>
Cc: 29095 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Wed, 01 Nov 2017 20:21:13 -0400

Alexander Shukaev <emacs <at> Alexander.Shukaev.name> writes:

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

Indeed, I didn't really think so.  But I've been thinking a lot about
how to avoid threads which devolve into bitter sniping (which is more
common than I'd like in emacs-devel/bugs), and I think calling such
things out at the beginning could help avoid misunderstandings.

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

In this context, "stable" just means no features are getting added.
Ideally no bugs either, but sometimes bug fixes end up adding bugs too.

> And that's what I just finished doing, voilà:
>
> e1f6e3127a292e6ba66d27c49ddda4fe949569f5
> Author:     Noam Postavsky
> AuthorDate: Wed Aug 30 23:12:22 2017 -0400

Hah!  It was me ;)

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

Versions 25.3 and lower all had this wait, and removing it cause some
problems for other users (see Bug#25521 and Bug#25511).  Therefore it
was restored in emacs-26 (and (almost) everything in emacs-26 goes to
master) with the option to remove it.  In fact, the wait used to be
unbounded, so a timeout is something of a compromise.

What confuses me though, is how a 100ms delay is adding ~50s to your
starup time?!  Or are you just creating 500 frames on startup?

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

Just to clarify, you have garbage-collection-messages set to non-nil on
purpose?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.