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: Wed, 20 Sep 2023 14:28:01 +0300 Message-ID: <83y1h1axtq.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> <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35446"; 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 Wed Sep 20 13:29:01 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 1qivO9-0008xK-GT for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 13:29:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qivNL-0002lV-0f; Wed, 20 Sep 2023 07:28:11 -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 1qivNE-0002ku-0z for emacs-devel@gnu.org; Wed, 20 Sep 2023 07:28:05 -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 1qivN9-0003ei-OM; Wed, 20 Sep 2023 07:28:01 -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=YFmUzSdEHXe9sXs/Tle+cKah+mhQtlMVBLhMmifdLuE=; b=MF8OyFoC8S3M Y1aLZtvhg3Y8IAZSbcftxqPBaLF6iofmEQ58P85f9aIj/aO1ckraQurX7s1sXiQ2DXEKfbR3nJAtJ ecqRxY75O3KunvlcS35iQFJJ0Ianpe1lq5FPXfj3mQXNXg4ujcVWxuYIl4xlgeSCejgTDpHXXRpKO 3TrP+Sy6Pw7huy8fSh563Qt3n6XJ0FaZfi1D6Zkt5lI7B0Oo/e/mAJBsfqfcfo/7AjjJAGUE5Wv+9 9aqiEmgCP/Hj/5zCcxSMqcT5VgCH/aVJr6iAHMi1DXPQLZ61bzwoLcWmKsEKHJc1mpfId8KrrAcqg EJbmnjEiC3oQhTenxz8DUg==; In-Reply-To: <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> (message from Dmitry Gutov on Tue, 19 Sep 2023 23:21:46 +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:310818 Archived-At: > Date: Tue, 19 Sep 2023 23:21:46 +0300 > Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > From: Dmitry Gutov > > On 19/09/2023 20:54, Eli Zaretskii wrote: > > > > 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. You are considering only the redisplay of that single window which has long lines. But what about the other windows, which perhaps don't have long lines? And what about the main thread of Emacs itself, which freezes for as long as redisplay didn't finish, thus preventing user interaction and responsiveness in general? These factors should not be neglected. > But I think we've much improved on the issue by reducing the complexity > instead (correct me if I'm wrong here). If you mean the long-lines improvements in Emacs 29, then we traded off correctness in at least some cases. It wasn't for free. > > 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. With enough text properties and overlays, you can definitely see a tangible slowdown in frame rate. E.g., Org developers don't want to use text properties because they slow down redisplay, and thus they consider them not scalable enough. > > 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). On the high-level design level, it should be clear without any need for benchmarking that separating redisplay from the main thread could bring benefits. Isn't that what every GUI application out there does? So trying to think about that is always a good thing, IMO.