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: Wed, 14 Dec 2022 15:57:47 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: monnier <at> iro.umontreal.ca, larsi <at> gnus.org, 58558 <at> debbugs.gnu.org
> Date: Wed, 14 Dec 2022 13:26:15 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Anyway, the fact that the time doesn't get worse when you GC between
> > benchmark most probably means that we produce a lot of garbage markers
> > (i.e., temporary markers that very quickly become unreferenced), and
> > they get in the way of buf_bytepos_to_charpos.
> 
> Most likely, but it is only part of the problem. If these temporary
> markers where the only problem, I would not see gradual performance
> degradation as I continue Emacs session (`garbage-collect` is called
> anyway during normal usage).

We've only seen perf profiles for the benchmark, and they point
squarely at buf_bytepos_to_charpos, which AFAIU means markers.  To
identify other potential causes, we need to see profiles for other
patterns of usage.  For example, profile collected when the benchmark
is run at the beginning of the session compared with profile from
benchmark after several hours.  I thought you already posted such a
comparison, and it, too, pointed at buf_bytepos_to_charpos?  Which
would probably mean that the amount of markers is increasing, albeit
more slowly, even through GC collects some of them.

Did you try to see how the number of markers in the buffer evolves
with the up-time?

Previous Next

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