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 19:52:30 +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 17:43:36 +0000
> 
> > If no other idea to find this out comes up, maybe run this with a
> > breakpoint in make-marker, look at the backtrace to see the callers.
> 
> I tried gdb now with break Fmake_marker.
> 
> The benchmark itself does not trigger the breakpoint.
> However, a huge number (hundreds) of breakpoint hits is generated upon
> finishing the benchmark execution.
> 
> bt:
> 
> #0  Fmake_marker () at alloc.c:3736
> #1  0x00005555557bb750 in Fmatch_data (integers=0x0, reuse=0x0, reseat=0x0) at search.c:2903

Ha-ha, shooting ourselves in the foot!

Great sleuthing job.  Now we need to think what to do with this.
Hmm...

> If I read the backtrace correctly, something in my custom mode-line is
> triggering Fmatch_data that creates markers.

Yes, you have sone :eval form in the mode line, it seems?

Calling xbacktrace will show a Lisp backtrace, which could be
educational here.

> But that code has not changes for years from git log.
> 
> One suspicious thing is that my code gets called that much frequently
> (100s of times) by redisplay. Not sure if it is normal.

You cannot predict when redisplay decides to redraw the mode line.

Previous Next

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