bug#58558: 29.0.50; re-search-forward is slow in some buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 58558@debbugs.gnu.org
> Date: Wed, 14 Dec 2022 13:23:02 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think I'm confused now: what do you mean by "executing the
> > benchmark"?  I thought the problem was that each "execution of the
> > benchmark" was slower than the one before it, in which case markers
> > added between benchmarks _are_ relevant.  But you say they aren't?
> > What did I miss?
> 
> Increasing time of running benchmarks is just a symptom.
> The real issue I am experiencing is that re-search-forward becomes
> slower as I keep using Emacs. `garbage-collect' helps, but not in a long
> term.
> 
> Basically, running
> 
> M-: (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t)))
> 
> - right after starting Emacs is taking 3-4 seconds.
> - after several hours -- 10-20 seconds
> - in Emacs 28, <1 sec.
> 
> Markers may or may not be a problem.

What else could slow down buf_bytepos_to_charpos so much?  All it does
is examine markers.

> f they are, it is not necessarily related to markers created when I
> run the benchmarks. May also be some markers created during the
> Emacs session.

Which means massive creation of markers could be the reason,
regardless of what causes such massive creation.  Right?  But if so,
why did you say that markers created by some timer(s) were not
relevant?

Btw, did you try to compare the number of buffer markers in Emacs 28
and Emacs 29/30, under this scenario, when the search becomes slow
enough?