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 17:35:51 +0300 Message-ID: <83il84c3p4.fsf@gnu.org> References: <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> <83y1h1axtq.fsf@gnu.org> <87cyyd8487.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 20 16:37:16 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 1qiyKK-000AT7-8T for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 16:37:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiyJI-0004DA-LH; Wed, 20 Sep 2023 10:36: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 1qiyJG-0004Ct-Lj for emacs-devel@gnu.org; Wed, 20 Sep 2023 10:36:10 -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 1qiyJC-0001vi-Up; Wed, 20 Sep 2023 10:36: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=ErjQgd8HOOZlgdnXLrIC9KBTehvqoxqQBod88Jv0OM0=; b=J2jFO6f22Wv3 8T3xSJMtNjMYVbL2R5K8Yq7rejib4H0VxnnVaMu9sykHhbluc6fhFC9P1NWaKKMCBlkJDMbZIlANJ Pv2Ulro+ockUZP5PwGkd9eMS72nOYMGvhXDudX2pPorVVfUYi0JTenpe3OfjMoal2JXlnowI4DC5Y 2gfZHsF5oJAVEP8DR3Kh7Q7Ne4qlW+vEmeITc0GBD/TOCIWFHRyA2NAjGQp4/+yXTqPcqe0WFbwiO KK/CC0YG0d5ljSicagl5qnlOaOdOw4EF8/Ur7hIsck/e+AW8IDPNszeoGBPH67JaBOhQNu8DFq8dS 0PMJHVcAMJk4TgfSp+17Ug==; In-Reply-To: <87cyyd8487.fsf@localhost> (message from Ihor Radchenko on Wed, 20 Sep 2023 11:38:00 +0000) 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:310838 Archived-At: > From: Ihor Radchenko > Cc: Dmitry Gutov , acm@muc.de, incal@dataswamp.org, > emacs-devel@gnu.org > Date: Wed, 20 Sep 2023 11:38:00 +0000 > > Eli Zaretskii writes: > > > 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. > > I do not think that it needs be addressed by async threads. > The main problem with text properties, AFAIK, is that segment tree Emacs > uses makes searching for next single property change scale with the > total number of segments where _any_ arbitrary property changes, not > with actual number of that searched property segments. Regardless of all of the above, any expensive processing that can be divided between several execution units will take less elapsed time, right? So, for example, processing text properties of two buffers sequentially by the same thread (as this is done now) will take longer than processing them concurrently in parallel, right? So redisplaying two windows by two independent threads running concurrently on two execution units will be faster, right? > I believe that it is more a question of rewriting text property handling > into multiple segment trees dedicated to individual properties. Not as far as redisplay is concerned, no. The display engine _wants_ to look for the next change in any text property, because it processes them all "together". That is, it finds the buffer position where any of the text properties change, then hands that position to each of the known methods for handling property changes so that each one of them does its thing.