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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 58558 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#58558: 29.0.50; re-search-forward is slow in some buffers
Date: Tue, 13 Dec 2022 16:28:31 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: larsi <at> gnus.org, monnier <at> iro.umontreal.ca, 58558 <at> debbugs.gnu.org
> Date: Tue, 13 Dec 2022 13:32:13 +0000
> 
> > 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.

AFAIR, you can ask perf to profile a single function, and you can ask
it to annotate the profile with the source code.

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

OK, so it looks more and more like each call becomes more expensive
for some reason.  But let's see the numbers before jumping to
conclusions.

Previous Next

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