Re: Long lines and bidi [Was: Re: bug#13623: ...]

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs development discussions <emacs-devel@gnu.org>
> Date: Fri, 08 Feb 2013 10:33:08 -0500
> 
> > So the first question is: is it feasible/possible/desirable to detect
> > that the buffer has no R2L text at all and automatically force
> > bidi-paragraph-direction to left-to-right and bidi-display-reordering
> > to nil?
> 
> Would this speed things up by a constant factor, or would it actually
> remove an O(N) factor?

The former, because the bidi iteration is slower than the original
unidirectional one by a constant factor, on the average.

> I think a fix will need more than a constant factor speed up.

Indeed.

> Did you check both the truncate-lines=nil and the truncate-lines=t cases?
> I think that for the truncate-lines=t case, we won't be able to avoid
> the O(linelength) slowdown (but we should try and skip the non-displayed
> part of lines faster, especially when there's no
> `display/after/before-string' property).

The problem is not with the part of text we actually display, because
the number of characters shown in a window does not depend on whether
we have truncate-lines=t or nil.  The problem is that most redisplay
operations always scan some text that is eventually not shown in the
window.  The longer the lines, the more text we scan that is outside
of the window.

For example, any redisplay that needs to scroll the window up (M-v
etc.) needs to find the buffer position for the window start.  To do
that, we use move_it_vertically_backward, which moves N screen lines
up (back) in the buffer.  But what that function does is move N
_buffer_lines_ back, and then moves forward by screen lines to find
which position is N screen lines above where we started.  If each line
is hundreds or thousands of characters, it is clear that moving back N
buffer lines will move much more than needed, and thereafter moving by
screen lines back through all those thousands of characters wastes a
lot of CPU cycles.