GNU bug report logs - #9470
24.0.50; Possible bidi-related slowness

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9470 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#9470: 24.0.50; Possible bidi-related slowness
Date: Mon, 12 Sep 2011 22:21:54 -0400

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

Previous Next

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