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