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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

"fast" (emacs 28) session does not have this call tree contributing
significantly.

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

We only established that the number of markers cannot be the problem.
However, buf_bytepos_to_charpos still dominates CPU samples (see the
attached) in Emacs master, but not in Emacs 28.

Unless there is some other place in buf_bytepos_to_charpos that may be
slow, the only possible explanation is that it simply gets called more
times.

Then, we are interested in the callers of buf_bytepos_to_charpos. That's
exactly what I provided in the previous message.

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

re_match_2_internal calls SYNTAX_TABLE_BYTE_TO_CHAR in a loop. So, if
something strange is happening with the loop, we may be calling
buf_bytepos_to_charpos more.

emacs-28-report.png
Description: PNG image

emacs-master-report.png
Description: PNG image

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>