bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+

[Mitchell]

On Sat, Jun 22, 2024 at 12:58 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Mitchell <mitchellahren@gmail.com>,  71644@debbugs.gnu.org
> > Date: Fri, 21 Jun 2024 17:06:31 -0400
> >
> > >   commit 8783700b23e70874c4996908bf02c010ae6f3fe1
> > >   Author:     Stefan Monnier <monnier@iro.umontreal.ca>
> > >   AuthorDate: Tue Aug 2 10:38:53 2022 -0400
> > >   Commit:     Stefan Monnier <monnier@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?

Eli, after Ihor and Stefan were able to reproduce it now, would it still be helpful for me to do this and report back? I’m more than happy to if it would help in any way.

Also should I be replying to the renamed thread from now on? (i.e., "chars==bytes (was: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+") This is my first bug report, so I’m not sure the etiquette, haha.