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

[Eli Zaretskii <eliz@gnu.org>]

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

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