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

Previous Next

Full log

Message #59 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, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#58558: 29.0.50; re-search-forward is slow in some buffers
Date: Tue, 13 Dec 2022 08:27:34 -0500

> The fraction of buf_bytepos_to_charpos increases over repeated benchmark
> runs.
[...]
> Any ideas what I can do further?

As usual, the problem is either that we call this function too often or
that it takes too much time every time we call it so:

- Try and figure out who is the most frequent caller of
  `buf_bytepos_to_charpos` during your benchmark.  Most calls to this
  function can usually be eliminated by changing the code to keep track
  of both bytes and chars at the same time.  Actually, most of the time
  we already have the char info somewhere nearby, so it might be
  a simple change.
  `gprof` can often give that info.

- Try and figure out why `buf_bytepos_to_charpos` is so slow.
  Last time we tweaked that code, AFAIK, is commit
  b300052fb4ef1261519b0fd57f5eb186c2d10295.
  My debugging approach for those cases is the following:
  DEFVAR_LISP a new variable in which you put a vector of N integers
  (initialized to 0), and then at various "interesting" points in the
  `buf_bytepos_to_charpos`, increment one of the vector elements.
  This way you can see from ELisp how many times each "interesting"
  point was executed.
  IOW, I do the profiling counters by hand.


        Stefan

Previous Next

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