bug#9470: 24.0.50; Possible bidi-related slowness

[Stefan Monnier]

>> I do assume we have some way to flush the cache (or parts thereof)
>> that become invalid, tho.
> If we add the necessary code to prepare_to_modify_buffer, yes.  That
> code will need to either update the START and END positions or
> invalidate the cache, depending on what modification is about to
> happen.  But not if the change is to add or remove text properties.

We don't have to pay attention to text properties, but I guess you're
right that the cache can surprive changes to text-properties.

> We will also need to invalidate the cache whenever the iterator
> position winds up outside the (START..END) region, and update it as we
> cross paragraph boundaries during iteration.

I don't see why, in general (you'd just flush the cache when a request
comes in for a different paragraph, i.e. to make room for another piece
of data), but in either case I don't think it would make much of
a difference, since the main use case if for a very long paragraph which
presumably covers the whole window.

>> > Any of these edits could insert or delete a paragraph boundary, and
>> > thus potentially change the paragraph direction.
>> Sure.  But if there aren't any edits, the cache is still valid.
> If there are no edits _and_ point didn't move before START or far
> after END.

Right: movement within a paragraph.  If there are edits nearby, you can
still re-scan from the edits, so it's still fast.

> Having the first command take 5 seconds is still going to annoy.  We

Yes.  Improvement to the worst case is better.


        Stefan