GNU bug report logs - #58558
29.0.50; re-search-forward is slow in some buffers

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Sun, 16 Oct 2022 01:27:02 UTC

Severity: normal

Found in version 29.0.50

Full log


Message #170 received at 58558 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58558 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#58558: 29.0.50; re-search-forward is slow in some buffers
Date: Mon, 10 Apr 2023 12:24:23 +0000
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> 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 (image/png, attachment)]
[emacs-master-report.png (image/png, attachment)]
[Message part 4 (text/plain, inline)]
-- 
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>

This bug report was last modified 2 years and 63 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.