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 19:04:13 +0200 [thread overview]
Message-ID: <83wqui7n5e.fsf@gnu.org> (raw)
In-Reply-To: <51152625.9070301@yandex.ru>
> Date: Fri, 08 Feb 2013 20:21:57 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 02/08/2013 06:07 PM, Eli Zaretskii wrote:
>
> > 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.
>
> (defun scroll-both ()
> (interactive)
> (let ((start (float-time)))
> (progn
> (dotimes (n 100) (progn (scroll-up) (redisplay)))
> (goto-char (point-max))
> (dotimes (n 100) (progn (scroll-down) (redisplay)))
> (message "Elapsed %f seconds" (- (float-time) start)))))
>
> With bidi, ~600 second elapsed, and:
>
> 25.18% emacs emacs [.] scan_buffer
> 7.04% emacs emacs [.] bidi_resolve_weak
> 6.47% emacs emacs [.] get_next_display_element
> 6.37% emacs emacs [.] bidi_level_of_next_char
> 5.14% emacs libc-2.16.so [.] __memcpy_ssse3_back
> 5.05% emacs emacs [.] move_it_in_display_line_to
> 4.94% emacs emacs [.] x_produce_glyphs
> 4.84% emacs libXft.so.2.3.1 [.] XftCharIndex
> 3.72% emacs emacs [.] bidi_move_to_visually_next
> 3.70% emacs emacs [.] next_element_from_buffer
> 2.90% emacs libXft.so.2.3.1 [.] XftGlyphExtents
> 2.05% emacs emacs [.] bidi_fetch_char
> 2.02% emacs emacs [.] lookup_glyphless_char_display
> 2.01% emacs emacs [.] bidi_resolve_neutral
> 1.76% emacs emacs [.] bidi_cache_iterator_state
> 1.70% emacs emacs [.] bidi_get_type
> 1.51% emacs emacs [.] bidi_resolve_explicit_1
> 1.18% emacs libXft.so.2.3.1 [.] XftFontCheckGlyph
> 1.12% emacs emacs [.] xftfont_encode_char
> 1.01% emacs emacs [.] xftfont_text_extents
>
> Without bidi, ~230 seconds elapsed, and:
This is consistent with my past measurements:
(a) disabling bidi makes redisplay faster, but it is still awfully
slow (2.3 sec per scroll);
(b) bidi iteration is about 2 times slower than the unidirectional
one (you get 3 times slower because your buffer is full of weak
characters, which make the bidi iterator work harder due to the
requirements of the Unicode Bidirectional Algorithm.
> I suspect that scroll should be direction-agnostic in theory
That theory is wrong. The reason is that functions that move by
display lines can only move forward. So moving backward is coded very
differently (a.k.a. "slower").
> but both profiled runs shows that scroll-down is much, much slower
> than scroll-up (that's why elapsed time is so huge in both cases).
That's expected; see also my explanation in a previous mail, which
describes what move_it_vertically_backward does. That function is
used a lot by scroll-down.
> > 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.
>
> Your guess is correct; but I suspect that an average text in human language
> contains less punctuations, digits and blanks than the C source code of the
> same size :-).
An average C code still has only a small fraction of punctuation.
Just look at any C file.
> > 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.
>
> Hm... insert-file-contents tries to detect encoding by looking at first 1K
> and last 3K of the file. Why the similar approach isn't applicable to bidi?
No. Detecting encoding by a small portion is a heuristic that works
only because most every file is encoded consistently. When a file is
encoded inconsistently, the result of the above decoding heuristic is
horribly wrong, and the consequences for the user are grave. As a
recent example, see bug #13505.
By contrast, scripts used in a text file do not have to be consistent
or uniformly distributed over the file at all. So the probability to
get this wrong will be much higher.
next prev parent reply other threads:[~2013-02-08 17:04 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 [this message]
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=83wqui7n5e.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.