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: line buffer as Red Black Trees instead of linear Date: Fri, 16 May 2014 08:41:48 +0300 Message-ID: <83fvkamg9v.fsf@gnu.org> References: <83mwein6w1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1400218931 24425 80.91.229.3 (16 May 2014 05:42:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 May 2014 05:42:11 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alin Soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 16 07:42:05 2014 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 1WlAuB-0001nr-70 for ged-emacs-devel@m.gmane.org; Fri, 16 May 2014 07:42:03 +0200 Original-Received: from localhost ([::1]:33469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlAuA-0002xg-Rq for ged-emacs-devel@m.gmane.org; Fri, 16 May 2014 01:42:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlAu3-0002qe-7a for emacs-devel@gnu.org; Fri, 16 May 2014 01:42:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlAty-000197-25 for emacs-devel@gnu.org; Fri, 16 May 2014 01:41:55 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:55281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlAtx-00018z-Pq for emacs-devel@gnu.org; Fri, 16 May 2014 01:41:49 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N5N00500JBTYE00@mtaout26.012.net.il> for emacs-devel@gnu.org; Fri, 16 May 2014 08:38:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5N0015JJOK3860@mtaout26.012.net.il>; Fri, 16 May 2014 08:38:45 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:171871 Archived-At: > Date: Fri, 16 May 2014 02:40:00 +0300 > From: Alin Soare > Cc: Stefan Monnier , emacs-devel@gnu.org > > > > Emacs works bad with buffers with long lines. This would work well, and > > all > > > the others atomic operations, like random access, search, will preserve > > the > > > current speed. > > > > You cannot help redisplay with long lines by giving it random access > > to buffer text. > > > > > This is right. Redisplay is one, and computing the result of some functions > is another thing. > > I did not check the flow of the calls that take place in that situation, > but I am sure that it happens at the level of buffer access, Some atomic > procedures of access to buffer are linear in time, instead of constant or > logarithmic in the worse case. Not in redisplay. It always moves to the next character, and remembers the last place it was at, so it mostly only needs to advance to the next character.