GNU bug report logs - #76538
31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: pipcet <at> protonmail.com, eller.helmut <at> gmail.com, Gerd Möllmann <gerd.moellmann <at> gmail.com>, joaomoreira <at> gmx.se, Eli Zaretskii <eliz <at> gnu.org>, 76538 <at> debbugs.gnu.org
Subject: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.
Date: Thu, 27 Feb 2025 15:54:18 -0500

> FYI, I tried various tweaks to that loop while debugging and concluded
> that DO_MARKERS loop is not the main bottleneck in this particular bug
> report.

The DO_MARKERS is probably not the main bottleneck nowadays, because the
code explicitly reduces the "estimated benefit" of remaining in the loop
at each iteration and exits once that gets too small.

But that just pushes the problem to the subsequent bytes-scan.

The main problem is simply that we need to make sure some nearby
(cache-)marker is found near the "beginning" of the set of markers we
consider.  Once this set becomes large the ordering between the markers
becomes super-important.  The code on `master` behaves a bit like an
"move to front" policy which works fairly well for the usual locality
properties of buffer navigation, whereas the code on the `igc` branch
has a tendency of putting new entries near the end where they risk not
being found at all, making the cache ineffective.

> I am wondering if anyone else is able to reproduce the problem locally.

I haven't looked at the recipe yet, TBH.
But I strongly suspect that you're seeing something similar to what
happens in the `bytechar-100k-random` benchmark in Helmut Eller's email.


        Stefan

Previous Next

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