From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Tue, 19 Sep 2023 23:21:46 +0300 Message-ID: <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> 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> <837comcam8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20655"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 22:22:45 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 1qihF4-000537-VZ for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 22:22:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qihEL-0008Rv-ES; Tue, 19 Sep 2023 16:21:58 -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 1qihEH-0008Ph-CM for emacs-devel@gnu.org; Tue, 19 Sep 2023 16:21:53 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qihEE-0004KA-Lg; Tue, 19 Sep 2023 16:21:52 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 73F125C0164; Tue, 19 Sep 2023 16:21:49 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 19 Sep 2023 16:21:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695154909; x=1695241309; bh=qwgBlI7hwsHD16rHOD8kHUvZAnQMGN/40j9 gwwLa1uo=; b=GD4E/GsFzMgguKC8spc7FTawQ7zLdLCRTEBPySLQ2sC+CXTjUFP TSOAPLMpAvF9fMpCVG3HRrtvP6H89BvE2zs1FNBxZ7otcZICcUby2uyqb7DYngP/ LeZngz8PkjRRUoW7diUybBApCRjeDsu6aRibU3HxZJ35VR99rT3docE4msfyl8Z+ qY1zcjbZQ5cXmbu7rFmHF+UQxrm+6yBw5O2DYhynAfVc7fprIhf8VrzTl18XkJOl 9ipp9y4p8i0DqFw+nPggbEkKlCEZASaP3W0F+vqpJQt2dGyRH1b4dr/u3ko6Ql4Y IkufvYmwt6fEm3K9eahtblhv5f6DLwYwbXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695154909; x=1695241309; bh=qwgBlI7hwsHD16rHOD8kHUvZAnQMGN/40j9 gwwLa1uo=; b=C9iJdprrk2DI0LGA0KRw20BFaycWZUBbqUO3tDlCL76UKERNFo7 26XdgsbBsdYLVlKpqEDjKjsv64khoQiBOzjjBUQaXFCYQj+JQ60aJH6MNw9MTKJj /2hwOlHLuPYqjRnrfl7/cJhYW8K1456UZEv57g8iTYUX15iXdiM56L0OXNzYBM9B nBQFSny/ZJB+XwV1Jzj2z1ZPqeLFlh/Sek+PPj4CRmxRP4HcCEPvQnUcB71OYrLN /IDi0II4ca4HhBzEMyfryLBqmoPdmJ8dmGOMn8pDJMA1C3Z6lslsNp+Bs5jJQ272 kNJQ2dQQn0BKcQSD0ppUu/Y+kZBK2DV5c9A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekuddguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 19 Sep 2023 16:21:47 -0400 (EDT) Content-Language: en-US In-Reply-To: <837comcam8.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.26; envelope-from=dmitry@gutov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:310795 Archived-At: On 19/09/2023 20:54, Eli Zaretskii wrote: >> 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. It's not 100%, but seems logical: the problem with long lines is that displaying a single line took non-linear amount of time proportional to its length. To be able to layout it in parallel, we would somehow have to be able to split it into independent pieces (perhaps using some caching mechanism?, IDK). If we are actually able to do that (which seems difficult), a non-parallel redisplay algorithm should happily use the same mid-line checkpoint information to work on smaller pieces of the line, likewise increasing the speed. But I think we've much improved on the issue by reducing the complexity instead (correct me if I'm wrong here). > 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? I was looking for other examples, to be honest. Like, for example, evidence that redisplay is something that keeps an average Emacs session from running at 60fps. Or even at 30fps. That would make it a bottleneck. When I asked the question, I was under the impression that people do have some data to point this way, and I just missed it. > 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. It is my experience that good benchmarking often helps with changing the design as well. Or coming up with a new one (there are a lot of options for how one could proceed). I'm not saying it is necessary, but it is a good idea, I think. > 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? Sure.