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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mitchell <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: 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).

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


        Stefan

Previous Next

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