From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Gap buffer problem?
Date: Wed, 11 Dec 2024 08:50:40 +0000
Message-ID: <87bjximwnj.fsf@protonmail.com>
References: <mailman.39.1723910423.12184.emacs-devel@gnu.org>
 <8634iyf257.fsf@gnu.org>
 <CADwFkmmUszzCDmjVrrw6wwKuB4J34CK_SWKoLWa3eww0JqsrQw@mail.gmail.com>
 <8634iwex8q.fsf@gnu.org>
 <CADwFkmny8-5q48b6O=9bYSgkQc1f2J2vLOAxseLLW2Y5CRLCzQ@mail.gmail.com>
 <86wmg7bso1.fsf@gnu.org> <87cyhzmzbp.fsf@telefonica.net>
 <EVhYbq77EDuc-exR7m5k66LCSZx3Ob7elQF47bPRBTL81qSX0WDox7GiQPuyc8Y2fHO8K-_Tk3OTGo2sahL8bkd2eS_XrGLixyxgIYX6LgA=@protonmail.com>
 <m234iussa8.fsf_-_@gmail.com>
Reply-To: Pip Cet <pipcet@protonmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="12802"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: "Pip Cet via \"Emacs development discussions.\"" <emacs-devel@gnu.org>,
 =?utf-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es>
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@gmail.com>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 13:15:09 2024
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1tLLcS-0003Br-Uv
	for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 13:15:08 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1tLLbm-0001u8-C6; Wed, 11 Dec 2024 07:14:26 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <pipcet@protonmail.com>)
 id 1tLIQn-0004ZD-63
 for emacs-devel@gnu.org; Wed, 11 Dec 2024 03:50:53 -0500
Original-Received: from mail-4322.protonmail.ch ([185.70.43.22])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <pipcet@protonmail.com>)
 id 1tLIQh-0006kt-Po
 for emacs-devel@gnu.org; Wed, 11 Dec 2024 03:50:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1733907043; x=1734166243;
 bh=TIOuxBsZ9Gou8YluajsnFROGi45M/SPbNzuEtLklTpc=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=EpkdLHaZ0coymVP4jShrF6/VS7CXlLIvf9zvA9PXt5XdJXiB099sn0TJa86B7Bqy8
 n6ZNplIgIsTwFjf0l6JJTWCPrsXqWxyAxLSqhwh4En1UxZ/4aoMuKXWhrpdOqmogb9
 UHtG/UH0pJ3VFKnLzKMY/YjwICIqFDym0nhbnk5rOux5NaeWMZ1n0urr19jwT8rGwZ
 j5DX2ixsAdz2HOlr9Bn00NjizXAyqy8XNCBDECi0AMapr3kCPc+yxbr7H1UEncvDe9
 TG7CYSRY/VU42Fmrxj0c23XQCt7JSTvWCxtnIEb4mddMJQfeW1CIZ8QtR7W4DEBNHL
 1i0on4ooGZVBQ==
In-Reply-To: <m234iussa8.fsf_-_@gmail.com>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: ffa5649b75e48f4001a9cbbae25a4757dc7d1a64
Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com;
 helo=mail-4322.protonmail.ch
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
 RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Mailman-Approved-At: Wed, 11 Dec 2024 07:14:18 -0500
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:326348
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/326348>

Gerd M=C3=B6llmann <gerd.moellmann@gmail.com> writes:

> Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>
>> On Tuesday, December 10th, 2024 at 13:39, =C3=93scar Fuentes <ofv@wanado=
o.es> wrote:
>>> Eli Zaretskii eliz@gnu.org writes:
>>> > Maybe so, but why is such a long wait a problem? GC works, and
>>> > works well.
>>>
>>> Working on certain projects with lsp-mode is a miserable experience due
>>> to all the random pauses.
>>
>> To be fair, part of that may be the gap buffer problem rather than GC.
>
> Could you please tell more about the gap buffer problem?

Just anecdotes, I'm afraid.  My problem was a large buffer of test
descriptions for a programming language, and I was running the tests and
modifying the buffer to contain the output for each test in a block
after the test itself. That worked, but running several tests in
parallel, moving back and forth in the buffer to modify text as the
output came in ... not so much.

I also recall discussion somewhere (nullprogram.com, maybe) about
multiple cursors and the gap buffer, and that's also a potential use
case where the gap buffer would make things very slow.

> I've read a little about the tradeoffs between gap buffers, piece
> tables, ropes, but I'm wondering if there is something concrete already
> known for sure that is a performance problem in Emacs. Maybe a bug that
> has been analyzed or something.

I'd be very interested in such a bug. Replacing the gap buffer
assumption is quite hard: IIRC, the main problem is that the regexp code
has been hacked to support gap buffers but not other data structures, so
we'd need to do something about that.

> (I'm asking because I just recently encountered a performance problem
> when adding something to xdisp.c:27339 (with cc-mode, Eglot, Corfu), and
> editing there was so slow that it was absolutely no fun, and that on a
> an M1 pro. Haven't investigated the reason.)

Interesting. It may be worth it to try reproducing that and disabling
modes one by one to find out which one is at fault. I suspect that it's
overlays/the interval tree rather than the gap buffer per se (however,
if we ever replace the gap buffer code, we should make sure its
replacement actually handles buffer text and text properties/intervals
in an integrated manner, rather than storing just buffer text).

Pip