Subject: bug#77924: 31.0.50; [Feature branch] Change marker implementation

From: Stefan Monnier <[email-masked]>
Date: Fri, 25 Apr 2025 13:30:58 -0400

>   In the non-ASCII case it is used.  Re-indentation means text modification
>   which in turns leads to index invalidation and re-building the index as
>   needed.  Index invalidation discards the index from the modification
>   position to the end of the text.  Re-building goes from the last valid
>   position the index contains to the next position that is needed to do a
>   position conversion.

I don't see how that would explain such a large slowdown: re-indenting
the whole buffer means reindenting each line, one by one starting from
the first, where indentation of a line modifies only that line and
usually looks only at that line and preceding text.

So it should cause an O(1) rebuilding of the index: the index will be
flushed when we start indenting the first line, and after that it
will get progressively re-filled and there shouldn't be much more
flushing going on during that time because we rarely look much beyond
the point where we last flushed (and hence beyond the point where we
will next flush).

Rebuilding the index once should take a very small amount of time
compared to performing the indentation.

Also, such modifications patterns are not specific to reindentation, so...
"think if the same reasons could slow down other cases?"

        Stefan