From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Long lines and bidi [Was: Re: bug#13623: ...]
Date: Fri, 08 Feb 2013 16:07:23 +0200 [thread overview]
Message-ID: <838v6y99wk.fsf@gnu.org> (raw)
In-Reply-To: <5114FEBB.8020201@yandex.ru>
> Date: Fri, 08 Feb 2013 17:33:47 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Emacs development discussions <emacs-devel@gnu.org>
>
> On 02/06/2013 10:23 PM, Eli Zaretskii wrote:
>
> > Another area of redisplay optimizations would be the infamous
> > very-long-lines use case. (Personally, I think this one is the single
> > most important deficiency in the current display engine, by far more
> > important than any other display problem.)
>
> I tried to scroll (down from the beginning and then up from the end) the
> very pathological file (~150M with just ~500 lines) and got the following
> profile:
Profile alone is not enough. Please tell how did you "scroll",
exactly (which commands did you use), and please also show the
absolute times it took to perform each command.
> 8.59% emacs emacs [.] bidi_resolve_weak
What was in the file? bidi_resolve_weak high on the profile hints
that it was full of punctuation or digits or banks, which is not
really an interesting case.
> 7.92% emacs emacs [.] bidi_level_of_next_char
> 7.81% emacs emacs [.] get_next_display_element
> 7.12% emacs emacs [.] move_it_in_display_line_to
> 6.96% emacs emacs [.] x_produce_glyphs
> 5.06% emacs libc-2.16.so [.] __memcpy_ssse3_back
> 4.56% emacs emacs [.] next_element_from_buffer
> 4.38% emacs emacs [.] bidi_move_to_visually_next
> 4.26% emacs emacs [.] scan_buffer
> 3.04% emacs libXft.so.2.3.1 [.] XftCharIndex
> 2.93% emacs emacs [.] bidi_fetch_char
> 2.67% emacs emacs [.] bidi_cache_iterator_state
> 2.61% emacs emacs [.] lookup_glyphless_char_display
> 2.47% emacs libXft.so.2.3.1 [.] XftGlyphExtents
> 2.35% emacs emacs [.] bidi_resolve_neutral
> 1.95% emacs emacs [.] bidi_get_type
> 1.86% emacs emacs [.] detect_coding
> 1.70% emacs emacs [.] produce_chars
> 1.50% emacs emacs [.] bidi_resolve_explicit_1
> 1.18% emacs emacs [.] get_per_char_metric
> 1.13% emacs emacs [.] bidi_cache_search.constprop.4
> 1.01% emacs emacs [.] xftfont_text_extents
> 0.90% emacs emacs [.] bidi_explicit_dir_char
> 0.88% emacs emacs [.] bidi_resolve_explicit
> ...
>
> 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?
Ah, _that_ red herring... Why is that the first question? What were
the times with and without bidi-display-reordering in this file? In
my testing, the display engine performs awfully slow in both cases, so
even though turning off reordering makes it faster, it is still so
terribly slow that the problem is not going to be solved by that.
As to your question: how can we know what characters are or aren't in
the buffer without scanning it? And scanning the buffer is exactly
what bidi.c does.
As to bidi-paragraph-direction, the detection of the paragraph
direction is turned off for long paragraphs anyway. Again, does
setting bidi-paragraph-direction to left-to-right give you reasonable
performance in that file? If not, this is just another red herring.
Anyway, I think this is the wrong way to try to find the solution.
The problem is not that scanning is slower with the bidi display. (If
it were, we would see terribly slow performance with "normal" files as
well.) The problem is that _we_scan_too_many_characters_. See this
part of the profile:
> 7.12% emacs emacs [.] move_it_in_display_line_to
The display routines of the move_it_* family, which are heavily used
in scrolling, cursor movement, and just about any display operation,
_always_ scan each line from the beginning to the end, before they get
to the next line. When each line is very long, those scans are very
expensive. The way to make display significantly faster for long
lines is to avoid scanning entire lines. The problem is how to do
that without losing accuracy, e.g., without missing characters that
affect the line metrics.
IOW, our problem is to find clever algorithms and provide supporting
data structures for those algorithms, so that we could avoid scanning
very long lines in their entirety each time we need to move the
cursor. When we find these algorithms and code them, the bidi
"problem" will disappear without a trace.
next prev parent reply other threads:[~2013-02-08 14:07 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 [this message]
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
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=838v6y99wk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@gnu.org \
/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.