[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9470: 24.0.50; Possible bidi-related slowness

From: Stefan Monnier
Subject: bug#9470: 24.0.50; Possible bidi-related slowness
Date: Mon, 12 Sep 2011 22:21:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]