Subject: Re: 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.

From: Stefan Monnier <[email-masked]>
Date: Wed, 26 Feb 2025 17:40:26 -0500

>> BTW, now that I look at the code, maybe the problem you're bumping into
>> is that on the igc branch, (cache-)markers are added to the rear of the
>> array (as a first approximation), whereas on `master` they're added to
>> the front of the linked list.
>>
>> In `buf_charpos_to_bytepos` we scan the array/list starting from
>> the front, so once the array gets large we never reach the end of the
>> array where we would find the recently-created nearby cache-marker, so
>> instead of using that nearby (cache-)marker we end up creating a new one
>> and paying (again) for a costly long scan.
>
> That seems to match what's happening here, with the order of scanning to
> blame, but...
>
>> Maybe if we change the `DO_MARKERS` iteration to scan from the end,
>> we'd recover a behavior much closer to what we see on `master`.
>
> ...I tried doing that, and it didn't work.  Maybe I messed up somehow.

Hmm... yeah, maybe you messed up somehow, or maybe it's because of the
"as a first approximation":

Gerd's array of markers keeps a free-list so new markers are not really
always added to the end, but rather they're added "randomly" in the
reverse order where markers were removed from the buffer (until reaching
the end of this, at which point it's added to the end of the array).
If there are enough markers in the array, anywhere that's not very-near
the rear (or the front, depending on the order in which we scan) will
simply never be consulted during char<->byte conversion.  🙁

        Stefan