GNU bug report logs - #77924
31.0.50; [Feature branch] Change marker implementation

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com, 77924 <at> debbugs.gnu.org
Subject: bug#77924: 31.0.50; [Feature branch] Change marker implementation
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

Previous Next

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