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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, 58558@debbugs.gnu.org
> Date: Sun, 09 Apr 2023 19:54:49 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think we should first go back to using perf.  I don't think you
> > compared profiles for Emacs which just started with one that was
> > running long enough to show the slowdown.  Comparing such profiles
> > should at least give us a hint where to look.
> 
> I now tried perf record -g.
> I was able to narrow down the call tree of the problematic
> buf_bytepos_to_charpos calls:
> 
> 43.82%--Fre_search_forward
>  --43.81%--search_command
>   --43.78%--search_buffer
>    --43.78%--search_buffer_re
>     --43.33%--re_search_2
>      --36.39%--re_match_2_internal
>       --21.90%--SYNTAX_TABLE_BYTE_TO_CHAR
>        --21.57%--BYTE_TO_CHAR
>         --21.49%--buf_bytepos_to_charpos
> 
> Not sure if it is telling much.

How does this compare with a "fast" session doing the same?

And why are you once again focusing on buf_bytepos_to_charpos, when
you previously (presumably) established that it cannot be the problem,
since the number of markers doesn't change significantly?

> I also looked into git history and I can only identify significant
> changes in re_match_2_internal after Emacs 28 release.

It sounds like most of the time is not in re_match_2_internal itself.
But I think comparison with a "fast" session could help with ideas.

Thanks.