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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 58558 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#58558: 29.0.50; re-search-forward is slow in some buffers
Date: Mon, 10 Apr 2023 10:27:32 -0400

>>> 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 I thought, we already established around Dec 13 that most of the
time is spent in `buf_bytepos_to_charpos` (in other profiles).

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

That would be quite surprising.

BTW, when debugging such performance problem, I often resort to
a few `DEFVAR_INT` defining ad-hoc counter variables, then sprinkle
corresponding increments of those variables from various places
(typically function entry point, loops, ...).

That gives me a kind of "poor man's profiler", but with the advantage
that I can look at their value conveniently from within the affected
Emacs session.


        Stefan

Previous Next

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