From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Tue, 19 Sep 2023 20:54:07 +0300 Message-ID: <837comcam8.fsf@gnu.org> References: <83edizjn0v.fsf@gnu.org> <0518f65b-1dd1-6923-8497-da4d3aeac631@gutov.dev> <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <99e84ae7-b3aa-a009-5cb8-a75826343196@gutov.dev> <838r92cgxp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13201"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 19:55:12 2023 Return-path: 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 ) id 1qiewJ-0003Dv-Gg for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 19:55:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qievM-00045J-H4; Tue, 19 Sep 2023 13:54:12 -0400 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 ) id 1qievI-000453-QU for emacs-devel@gnu.org; Tue, 19 Sep 2023 13:54:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qievH-0000DE-26; Tue, 19 Sep 2023 13:54:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WpFrSsSvK8hmjzRdQ2p4nFMOYqrGlja3uh54bXD1rfY=; b=ocqnUtXV4Pkk E5jVQ6dz7a+QUW2dsKe57nD+Tzs36Zhz77EObEHhWvsRDP3xLEgJLGANOLvoroWxZuPWqZM9KoKcP H7cGE6bTRPkgVKhGrnoxfJxUeMlKSk30W+X1nY7t0nqlvfjaehmUhTdhGy6bYB7wvLlROkpb1diF1 DGIwaTHC0fBvBBLqeuhwhdIGQaKYwbEi4Cc1DCQJ9fmpXC9rzS6LzcqnSjX6nthw0SCvvn54b5Mob HLOpTlv4oNEy+Ze2N4RgnYmBsdxs+VtM8BHP8/QIx98OyOZBCzIQpDjVq67RLOQbWDZFrpbHU20Rt dNXCLZ3I5Btp/Y4roLdrnQ==; In-Reply-To: (message from Dmitry Gutov on Tue, 19 Sep 2023 19:01:31 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-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:310789 Archived-At: > Date: Tue, 19 Sep 2023 19:01:31 +0300 > Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > From: Dmitry Gutov > > >> Do we have evidence that the speed of redisplay is a limiting factor in > >> general Emacs usage? I.e. with an optimized build and most of the > >> popular modes (excepting certain display-heavy Org buffers, let's say). > > You already forgot the long-lines problems? > > The long-lines problem wasn't solvable with parallel redisplay either, > it was a case of high algorithm complexity (a combination of them). How do you know that parallel redisplay will not solve this? This can only be obvious when the detailed design of that is presented. Until then, it's anyone's guess. Anyway, you asked for evidence that redisplay could benefit from performance boost, and I gave you some. Now you for some reason want to claim that my evidence doesn't convince you, but it still is evidence, right? > It would help to see some info on: > > - Whether Stefan's build is optimized, > - How much time the many-frames case spends talking to the windowing > system, compared to the time our redisplay takes internally. If there > are many frames displayed, but the current buffer is shown in only one > of them (or two, etc), then shouldn't the rest of the frames stay mostly > still anyway? > > I also like to have my frames maximized, and I have a 4K display -- even > so, redisplay seems to be mostly fine (with 1-2 frames anyway). But > rendering large windows at high resolution, while it can be taxing, > generally bottlenecks at something else than the layout algorithms. > Unless you're arguing that the layouts are going to become more complex > exponentially as well. You seem to be opposed to attempts to explore ways of making Emacs less single-threaded than it is today, unless someone provides a proof, up front, that this will necessarily solve some particular problem? Why? what harm could that possibly do, if it succeeds? And if it doesn't succeed, at least we will have learned something probably useful for the future. The right time to ask the questions you are asking is when a more or less detailed design is presented, and we can assess the complexity and other possible downsides of the proposal against its gains, if any. We are not there yet. Let's keep our minds open and see where this leads us, okay?