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: monnier@iro.umontreal.ca, larsi@gnus.org, 58558@debbugs.gnu.org
> Date: Wed, 14 Dec 2022 13:26:15 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Anyway, the fact that the time doesn't get worse when you GC between
> > benchmark most probably means that we produce a lot of garbage markers
> > (i.e., temporary markers that very quickly become unreferenced), and
> > they get in the way of buf_bytepos_to_charpos.
> 
> Most likely, but it is only part of the problem. If these temporary
> markers where the only problem, I would not see gradual performance
> degradation as I continue Emacs session (`garbage-collect` is called
> anyway during normal usage).

We've only seen perf profiles for the benchmark, and they point
squarely at buf_bytepos_to_charpos, which AFAIU means markers.  To
identify other potential causes, we need to see profiles for other
patterns of usage.  For example, profile collected when the benchmark
is run at the beginning of the session compared with profile from
benchmark after several hours.  I thought you already posted such a
comparison, and it, too, pointed at buf_bytepos_to_charpos?  Which
would probably mean that the amount of markers is increasing, albeit
more slowly, even through GC collects some of them.

Did you try to see how the number of markers in the buffer evolves
with the up-time?