From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
Subject: Re: Long lines and bidi [Was: Re: bug#13623: ...]
Date: Fri, 08 Feb 2013 18:05:47 +0200 [thread overview]
Message-ID: <831ucq94f8.fsf@gnu.org> (raw)
In-Reply-To: <jwvzjze967w.fsf-monnier+emacs@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.
prev parent reply other threads:[~2013-02-08 16:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-03 22:05 bug#13623: 24.3.50; Redisplay issue with transient-mark-mode Lawrence Mitchell
2013-02-04 15:49 ` Eli Zaretskii
2013-02-04 17:20 ` Lawrence Mitchell
2013-02-04 18:10 ` Eli Zaretskii
2013-02-05 4:54 ` Dmitry Antipov
2013-02-05 12:07 ` Dmitry Antipov
2013-02-05 17:46 ` Eli Zaretskii
2013-02-05 17:45 ` Eli Zaretskii
2013-02-06 7:16 ` Dmitry Antipov
2013-02-06 14:31 ` Stefan Monnier
2013-02-06 15:14 ` Dmitry Antipov
2013-02-06 18:04 ` Eli Zaretskii
2013-02-06 18:23 ` Eli Zaretskii
2013-02-06 20:30 ` Stefan Monnier
2013-02-07 3:41 ` Eli Zaretskii
2013-02-08 13:33 ` Long lines and bidi [Was: Re: bug#13623: ...] Dmitry Antipov
2013-02-08 14:07 ` Eli Zaretskii
2013-02-08 14:46 ` Long lines and bidi Eli Zaretskii
2013-02-08 16:38 ` Dmitry Antipov
2013-02-08 16:52 ` Eli Zaretskii
2013-02-09 3:34 ` Paul Eggert
2013-02-09 8:46 ` Eli Zaretskii
2013-02-09 9:05 ` Paul Eggert
2013-02-09 9:33 ` Eli Zaretskii
2013-02-11 2:33 ` Paul Eggert
2013-02-09 10:01 ` Eli Zaretskii
2013-02-10 16:57 ` Eli Zaretskii
2013-02-11 5:43 ` Dmitry Antipov
2013-02-11 7:54 ` Dmitry Antipov
2013-02-11 16:47 ` Eli Zaretskii
2013-02-11 23:55 ` Paul Eggert
2013-02-11 16:42 ` Eli Zaretskii
2013-02-11 17:53 ` Dmitry Antipov
2013-02-11 18:10 ` Eli Zaretskii
2013-02-11 18:21 ` Dmitry Antipov
2013-02-11 17:17 ` Eli Zaretskii
2013-02-11 17:55 ` Drew Adams
2013-02-11 18:13 ` Eli Zaretskii
2013-02-08 16:21 ` Long lines and bidi [Was: Re: bug#13623: ...] Dmitry Antipov
2013-02-08 17:04 ` Eli Zaretskii
2013-02-08 15:33 ` Stefan Monnier
2013-02-08 16:05 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831ucq94f8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.