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

Previous Next

Full log

Message #86 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: Tue, 13 Dec 2022 13:15:05 -0500

> The benchmark itself does not trigger the breakpoint.

Does that mean that `Fmatch_data` is not called during a single
`re-search-forward` (not a surprise: you'd need to put a breakpoint on
`build_marker` to see the markers built by `buf_bytepos_to_charpos`)
but is called between `re-search-forward`, or that it's not called at
all during the whole benchmark where you perform several
`re-search-forward` which grow progressively slower?

If it's the latter, then those calls can't explain the slowdown, right?

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

The most common calls to `match-data` are from `save-match-data`.
And most uses of `save-match-data` are ill-advised (as the docstring
explains `save-match-data' should be used to save *your* match data
rather than your caller's match data), so you might like to double check
whether that call to `match-data` can be eliminated altogether.


        Stefan

Previous Next

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