GNU bug report logs - #71644
30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+

Previous Next

Full log

Message #47 received at 71644 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mitchellahren <at> gmail.com, 71644 <at> debbugs.gnu.org
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
 markers beginning in emacs 29+
Date: Sat, 22 Jun 2024 09:57:55 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Mitchell <mitchellahren <at> gmail.com>,  71644 <at> debbugs.gnu.org
> Date: Fri, 21 Jun 2024 17:06:31 -0400
> 
> >   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
> >   Author:     Stefan Monnier <monnier <at> iro.umontreal.ca>
> >   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
> >   Commit:     Stefan Monnier <monnier <at> iro.umontreal.ca>
> >   CommitDate: Tue Aug 2 13:06:51 2022 -0400
> >
> >       * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
> >
> > It changed the comparison operator in two places in marker.c.
> >
> > Curiously, the log message doesn't even mention the change in
> > marker.c, which could be a sign that this change was not intended to
> > be installed.  Stefan, did you intend to install it, and if so, do you
> > have any comments about this bug report?
> 
> Hmm... can't remember why/how it ended up in the above commit.
> Looks like an oversight.  But the change should be harmless: the
> `eassert` should make sure that the comparison gives the same answer
> either way (and AFAICT if/when the new comparison gives a different
> answer from the old code, the old code will loop until it segfaults).

Mitchell, can you try reverting that change, and see if that affects
performance in your case?

> > I'm a bit confused by the fact that I don't see the slowdown on my
> > machine, but maybe there are other factors at work here that hide
> > the regression.
> 
> The byte<->char conversion code is affected by many unrelated moving
> parts, so it can be difficult to come up with a reproducible recipe.

But in this case, we did that in "emacs -Q" and with a specific test
file that was posted and used.  What other variables can affect this
recipe?  Do you see the slow response on your machine, for example,
when running this recipe?

Previous Next

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