From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Long lines and bidi Date: Mon, 11 Feb 2013 18:47:43 +0200 Message-ID: <83d2w66bm8.fsf@gnu.org> 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> <836222983u.fsf@gnu.org> <51152A00.6070101@yandex.ru> <83y5ey7npl.fsf@gnu.org> <5115C3BC.8020203@cs.ucla.edu> <83txpl7u3w.fsf@gnu.org> <5116113D.5070707@cs.ucla.edu> <83mwvd7qlx.fsf@gnu.org> <83r4ko5cpv.fsf@gnu.org> <511884F5.6030806@yandex.ru> <5118A3D1.2050300@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360601265 4870 80.91.229.3 (11 Feb 2013 16:47:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 16:47:45 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 17:48:05 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 1U4wXy-0000Vx-DI for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 17:48:02 +0100 Original-Received: from localhost ([::1]:36374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4wXf-00052M-6Y for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 11:47:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4wXc-00052B-Pc for emacs-devel@gnu.org; Mon, 11 Feb 2013 11:47:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4wXb-0000Hd-8x for emacs-devel@gnu.org; Mon, 11 Feb 2013 11:47:40 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:55154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4wXa-0000HG-Pu for emacs-devel@gnu.org; Mon, 11 Feb 2013 11:47:39 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MI200L00EC0BK00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 11 Feb 2013 18:47:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MI200L4GENA0560@a-mtaout22.012.net.il>; Mon, 11 Feb 2013 18:47:35 +0200 (IST) In-reply-to: <5118A3D1.2050300@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:156961 Archived-At: > Date: Mon, 11 Feb 2013 11:54:57 +0400 > From: Dmitry Antipov > CC: Eli Zaretskii , Paul Eggert > > On 02/11/2013 09:43 AM, Dmitry Antipov wrote: > > > Yet another interesting profile (generated by scroll-both micro-benchmark with > > r111730) is shown below. > > > > Input is 4K lines, each line is ~27K bytes, Imla'ei (modern Arabic) script. IIUC > > this R2L text with long lines should push bidi really hard, but ... bidi core > > routines (by itself) are almost irrelevant in the profile: > > > > 39.96% emacs emacs [.] scan_buffer > > 28.72% emacs emacs [.] buf_charpos_to_bytepos > > 21.82% emacs emacs [.] buf_bytepos_to_charpos > > 0.59% emacs emacs [.] re_match_2_internal > > ... and with Paul's mem(r)chr patch it is: > > 43.38% emacs emacs [.] buf_charpos_to_bytepos > 28.42% emacs emacs [.] buf_bytepos_to_charpos > 13.10% emacs libc-2.16.so [.] memrchr > 0.85% emacs emacs [.] re_match_2_internal Without absolute times, it's hard to judge the improvement. > So I should vote YES. This is simple optimization which really makes sense, > and I suspect that the "less usual" input is, the more sense it has. I'm not opposed to using memchr where possible. I'm just saying that we should NOT regard this as any kind of solution for the long-lines problem with the current display engine. To fix that problem, we need to speed up redisplay by one or two orders of magnitude (it currently takes several hundreds of milliseconds to several seconds; it should take a few milliseconds, 10 msec max). That is a far cry from 25% improvement we will get with memchr.