GNU bug report logs -
#9470
24.0.50; Possible bidi-related slowness
Previous Next
Reported by: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Date: Sat, 10 Sep 2011 18:37:01 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #66 received at 9470 <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 13 years and 303 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.