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

Previous Next

Full log

Message #62 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: Tue, 13 Dec 2022 13:32:13 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The fraction of buf_bytepos_to_charpos increases over repeated benchmark
>> runs.
>
> So buf_bytepos_to_charpos is the main suspect now, I guess.  This
> could happen because either (a) buf_bytepos_to_charpos is called more
> times as session uptime progresses,

Just to clarify. The perf records I did are roughly for the duration of
benchmark-run calls. Nothing more.

> or (b) because each call to
> buf_bytepos_to_charpos becomes more and more expensive.  So I think
> the first question is: how many times is buf_bytepos_to_charpos called
> for each search, or, equivalently, is the CPU time per call used up by
> buf_bytepos_to_charpos stays stable or goes up?  I think perf can
> answer these questions if you ask nicely.

I will look how to do it. Maybe perf probe.
I guess, it will be useful to compile Emacs with debug symbols at this
point.

> Is the buffer in question being edited as time advances?  Or is buffer
> text and everything else in the buffer left unchanged?

Not edited between benchmarks. Remember that I did sequence of
benchmark-run calls and the time gradually increases.

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

Previous Next

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