From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Long lines and bidi [Was: Re: bug#13623: ...] Date: Fri, 08 Feb 2013 20:21:57 +0400 Message-ID: <51152625.9070301@yandex.ru> References: <877gmp5a04.fsf@ed.ac.uk> <83vca89izh.fsf@gnu.org> <5110906D.7020406@yandex.ru> <83fw1aac3d.fsf@gnu.org> <51120360.4060104@yandex.ru> <51127363.5030203@yandex.ru> <834nhp9u9j.fsf@gnu.org> <5114FEBB.8020201@yandex.ru> <838v6y99wk.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1360340533 15966 80.91.229.3 (8 Feb 2013 16:22:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 16:22:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 08 17:22:34 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U3qif-00009X-NS for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2013 17:22:33 +0100 Original-Received: from localhost ([::1]:49676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qiM-0003Ag-7y for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2013 11:22:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qiI-00037z-Q3 for emacs-devel@gnu.org; Fri, 08 Feb 2013 11:22:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3qiH-0001Fd-9O for emacs-devel@gnu.org; Fri, 08 Feb 2013 11:22:10 -0500 Original-Received: from forward16.mail.yandex.net ([2a02:6b8:0:1402::1]:39016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3qiA-0001DA-0f; Fri, 08 Feb 2013 11:22:02 -0500 Original-Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward16.mail.yandex.net (Yandex) with ESMTP id 823EAD22FB1; Fri, 8 Feb 2013 20:21:58 +0400 (MSK) Original-Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 5786218A00F5; Fri, 8 Feb 2013 20:21:58 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id LvWuMSbc-LvWWTMfY; Fri, 8 Feb 2013 20:21:58 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1360340518; bh=mDwL+o10LqhLrLLCIWU3EjCkGEhzrsRMzS/V0Vd+Eu8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cwJsMDztoCOXvtHvrhlJ1ZXCHsfaOOU8J00bSh+A3XQK6yehVnhLV47drdnOKVa19 Xqto4TNOsCvln2RuWf4zglGRtoox4snASKdWYJ2H69ckAnhlHeoruBN6PhpQXKcxSo ekFQqyE8EQfyMm0p2s+nDUqffnBXusJYj3KU1NXU= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 In-Reply-To: <838v6y99wk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a02:6b8:0:1402::1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156895 Archived-At: 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: 21.36% emacs emacs [.] x_produce_glyphs 17.92% emacs emacs [.] get_next_display_element 15.07% emacs emacs [.] move_it_in_display_line_to 8.37% emacs emacs [.] next_element_from_buffer 8.34% emacs libXft.so.2.3.1 [.] XftCharIndex 6.12% emacs emacs [.] lookup_glyphless_char_display 4.21% emacs libXft.so.2.3.1 [.] XftGlyphExtents 3.07% emacs emacs [.] xftfont_encode_char 2.68% emacs emacs [.] xftfont_text_extents 1.87% emacs emacs [.] get_per_char_metric 1.53% emacs libXft.so.2.3.1 [.] XftFontCheckGlyph 1.49% emacs emacs [.] composition_compute_stop_pos 1.35% emacs emacs [.] set_iterator_to_next cache-long-line-scans is nil in both cases. I suspect that scroll should be direction-agnostic in theory; 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). > 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 :-). > 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. 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? Dmitry