From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alin Soare Newsgroups: gmane.emacs.devel Subject: Re: line buffer as Red Black Trees instead of linear Date: Thu, 15 May 2014 22:47:27 +0300 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf303f6a0014b99e04f97591a4 X-Trace: ger.gmane.org 1400183261 28148 80.91.229.3 (15 May 2014 19:47:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 19:47:41 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 15 21:47:34 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 1Wl1cr-0007S2-7X for ged-emacs-devel@m.gmane.org; Thu, 15 May 2014 21:47:33 +0200 Original-Received: from localhost ([::1]:60225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1cq-0001oU-P0 for ged-emacs-devel@m.gmane.org; Thu, 15 May 2014 15:47:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1cn-0001nu-7r for emacs-devel@gnu.org; Thu, 15 May 2014 15:47:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wl1cm-0004RC-88 for emacs-devel@gnu.org; Thu, 15 May 2014 15:47:29 -0400 Original-Received: from mail-ig0-x22e.google.com ([2607:f8b0:4001:c05::22e]:52764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl1cm-0004R6-2Z for emacs-devel@gnu.org; Thu, 15 May 2014 15:47:28 -0400 Original-Received: by mail-ig0-f174.google.com with SMTP id h3so8371662igd.13 for ; Thu, 15 May 2014 12:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tpWa3ukaYJjmtQ0X835wHATd3dpgo/7vGQMYa/9rHcQ=; b=XhewDqckVEmaZPMnxD6c13vXGPzCM6jqzOgCtp4nCzif66yZt53ksE42Ouuz2TcT7/ gQcDRAqSlvnBZsvN6TNfYCWM5/hkSOn9/T3dkaxlhIaHKkCHjTn6GwOil4vcfRf0TkPi H5zI3S8gZz9XpJZucc5v1HPUF51a0y0jAflTX1PIgamP+oipHqyN8I7ZgPinbBP+hr4n 0H5YVsAjPSK1QXX4MtVE+Yqw5ZxA8vNu4HSMkVsbvOJxIqIwCNVRxVMBDFPfUtzLFJ9B XwCz0FBZbDG+S9NK/DtiCP/AjmE36cA1kwTuSuAuiBVJ9RJWXF8MBHZf8g56LUQZb8wb dZZw== X-Received: by 10.42.204.197 with SMTP id fn5mr904542icb.95.1400183247385; Thu, 15 May 2014 12:47:27 -0700 (PDT) Original-Received: by 10.43.142.70 with HTTP; Thu, 15 May 2014 12:47:27 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22e 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:171862 Archived-At: --20cf303f6a0014b99e04f97591a4 Content-Type: text/plain; charset=UTF-8 > > > The major improvement would be the redisplay. > > Actually, no. Redisplay scans the buffer linearly, so it would > be unaffected. > > I did not check recently which operations are called by redisplay, in order to see exactly where redisplay and other operations get stuck. But emacs works terrible with long lines. 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. Try this: (dotimes (j 10000) (dotimes (i 10000) (insert 1000) ) ) This will insert a random unicode character many times in each line, and many lines. Try to do these operations a few times: end-of-buffer (M->) and beginning of buffer (M-<). These are problems that arise with long lines, in which redisplay gets stuck. I did not check recently the atomic operations on buffer data structure, where emacs gets stuck, but I am sure that redisplay gets stuck in buffer data structure. For me the rediaplay works bad when a program outputs long lines in *shell* -- probably because it modify the gap many times, and redisplay gets stuck. Konsole of KDE for example, works perfectly with any kind of outputs from any process. --20cf303f6a0014b99e04f97591a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> The major improvement would be the redisplay.

Actually, no. =C2=A0Redisplay scans the buffer linearly, so it would<= br> be unaffected.


I did not check recently which operations are called by re= display, in order to see exactly where redisplay and other operations get s= tuck. But emacs works terrible with long lines.

Emacs works bad with buffers with long lines. This woul= d work well, and all the others atomic operations, like random access, sear= ch, will preserve the current speed.

Try this:= =C2=A0


(dotimes (j 10000)
=C2=A0= (dotimes (i 10000)
=C2=A0 =C2=A0 (insert 1000) ) )

This will insert a random unicode character many times in= each line, and many lines.

Try to do these operations a few times: end-of-buffer (= M->) and beginning of buffer (M-<).

These ar= e problems that arise with long lines, in which redisplay gets stuck. I did= not check recently the atomic operations on buffer data structure, where e= macs gets stuck, but I am sure that redisplay gets stuck in buffer data str= ucture.



For me the rediaplay work= s bad when a program outputs long lines in *shell*=C2=A0=C2=A0-- probably b= ecause it modify the gap many times, and redisplay gets stuck. Konsole of K= DE for example, works perfectly with any kind of outputs from any process.<= /div>



--20cf303f6a0014b99e04f97591a4--