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 19:17:28 +0200 Message-ID: <83bobq6a8n.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1360603080 23582 80.91.229.3 (11 Feb 2013 17:18:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 17:18:00 +0000 (UTC) Cc: eggert@cs.ucla.edu, dmantipov@yandex.ru To: emacs-devel@gnu.org, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 18:18:20 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 1U4x1E-0002Jh-Pa for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 18:18:16 +0100 Original-Received: from localhost ([::1]:60965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4x0v-0003JQ-HH for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2013 12:17:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4x0t-0003JB-7B for emacs-devel@gnu.org; Mon, 11 Feb 2013 12:17:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4x0r-00020w-7v for emacs-devel@gnu.org; Mon, 11 Feb 2013 12:17:55 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4x0q-00020Y-Tz for emacs-devel@gnu.org; Mon, 11 Feb 2013 12:17:53 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MI200L00ETKE600@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 11 Feb 2013 19:17:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MI200LWNG0VB870@a-mtaout22.012.net.il>; Mon, 11 Feb 2013 19:17:20 +0200 (IST) In-reply-to: <83r4ko5cpv.fsf@gnu.org> 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:156962 Archived-At: > Date: Sun, 10 Feb 2013 18:57:00 +0200 > From: Eli Zaretskii > Cc: emacs-devel@gnu.org > > I just committed to the trunk revision 111724 with a couple of simple > changes which speed up by a factor of 3 some redisplay operations, > such as M-v or M->, in a buffer with very long lines. Please try it. Further measurements indicate that the bottleneck is in searches for previous or next newline, or N-th previous/next newline. These searches are at the core of functions that compute pixel dimensions of buffer text, when the display engine needs to figure out where to start displaying the window after scrolling, or where to put point after C-p or C-n. As a typical example, a C-n in a buffer with truncate-lines set non-nil requires us to find the next physical line in the buffer, i.e. the next newline. We currently do that by searching forward in the buffer, one byte at a time, until we find a newline. If lines are very long, this is expensive. When truncate-lines is nil, this problem doesn't exist for C-n, but a similar problem exists for C-p: we need to find the _previous_ newline (which is many characters back when lines are long), and then scan forward until we find a character that is displayed one screen line above the one we were at when the user typed C-p. Revision 111724 makes sure we don't go back more than one physical line, unless really needed, but given the current design of the code, one full line is the absolute minimum. Turning on the newline cache speeds up these searches for a newline by a factor of 2, which is not too spectacular, but not negligible. Any objections to turning on that caching by default in all buffers? Beyond that, either we can find a much more efficient way of finding the next or previous newline, or we will need a complete redesign and re-implementation of the move_it_* family of functions, which is used a lot by the display engine.