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: Sat, 09 Feb 2013 10:46:11 +0200 Message-ID: <83txpl7u3w.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360399578 16667 80.91.229.3 (9 Feb 2013 08:46:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 08:46:18 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 09 09:46:39 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 1U464z-0000cm-PK for ged-emacs-devel@m.gmane.org; Sat, 09 Feb 2013 09:46:37 +0100 Original-Received: from localhost ([::1]:37067 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U464g-0007EB-65 for ged-emacs-devel@m.gmane.org; Sat, 09 Feb 2013 03:46:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U464d-0007Dt-E9 for emacs-devel@gnu.org; Sat, 09 Feb 2013 03:46:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U464c-0007xB-8f for emacs-devel@gnu.org; Sat, 09 Feb 2013 03:46:15 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U464c-0007x0-0D for emacs-devel@gnu.org; Sat, 09 Feb 2013 03:46:14 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MHY007002ZWR200@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 09 Feb 2013 10:46:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHY007D430XNN10@a-mtaout20.012.net.il>; Sat, 09 Feb 2013 10:46:10 +0200 (IST) In-reply-to: <5115C3BC.8020203@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:156911 Archived-At: > Date: Fri, 08 Feb 2013 19:34:20 -0800 > From: Paul Eggert > CC: Dmitry Antipov , emacs-devel@gnu.org > > On 02/08/2013 08:52 AM, Eli Zaretskii wrote: > >> > So, ~90% of time spent in scan_buffer is: > >> > > >> > 799 while (*cursor != target && --cursor >= ceiling_addr) > >> > 800 ; > > > Which cannot be optimized. > > It can be sped up somewhat, by using memrchr. > > This won't solve these performance issues, but it helps: > on my platform (x86-64 Ubuntu 12.10) I ran Dmitry's scroll-both benchmark > > on a real file (the trunk's src/xdisp.c), and it was 25% faster overall > (1.19 seconds versus 1.49 seconds) when I used memrchr there > and memchr for forward searches. 25% faster is still terribly slow for redisplay. xdisp.c doesn't have a problem in the first place (1.49 sec divided by 100 is 15 msec, not something users will notice, let alone the difference between 15 and 11 msec). And for files with long lines, these 25% will not solve anything, since 6 sec _per_scroll_, give or take 25%, is intolerably slow. I don't think we should make this optimization, because it optimizes in the wrong place. The problem is not with scan_buffer, the problem is that it (actually, its callers) get called way too much. This is a classic case where solving a slow operation needs a radical change in the algorithms, not loophole optimizations. > Most of the attached patch is boilerplate taken unmodified from gnulib, > to support memrchr on non-GNU platforms. The key part of the change is > at the end, to src/search.c. I don't understand why you removed the TARGET argument of scan_buffer. The fact that all its callers use it for looking for a newline doesn't mean it cannot be used otherwise. At the very least, the name of the function should be changed to reflect the change.