bug#9470: 24.0.50; Possible bidi-related slowness

[Stefan Monnier]

>> I'd guess that a cache that stores (START . END) could help, where
>> "START is a position that starts a paragraph and that paragraph ends no
>> sooner than END".
>> This way when working within a very long paragraph, you only need to
>> look for a paragraph boundary between END and point and if there isn't
>> any, you can go straight to START without searching for it.
> I'm not sure I'm following.  Are you assuming that redisplay is
> entered immediately after each deletion or insertion, and therefore
> these edits are always at point?

No.  I do assume we have some way to flush the cache (or parts thereof)
that become invalid, tho.

> 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.  And if
there are edits before START of after END, then the cache can still be
valid (tho it may need START to be a marker, of course).

> If you don't assume changes at point, then I don't see how point is
> relevant to this issue.  Am I missing something?

By "point" I just meant "the position we're interested in",
i.e. probably the first position of the text we're rendering.

> There are other complications with your proposal, e.g. the need to
> look for and keep track of paragraph end, which I currently don't care
> about, and the need to recompute the values of START and END when
> point moves far way.  But the above is the major one.

I'm sure there are complications and that it won't remove
all slowdowns.  But it should help the case in point (movement in
a very long paragraph) by only suffering the slow "find paragraph
beginning" once rather than for every command.


        Stefan