From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Thu, 21 Sep 2023 10:41:52 +0000 Message-ID: <87pm2bzu33.fsf@localhost> References: <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> <83il84c3p4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17951"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 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 Thu Sep 21 15:07:39 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 1qjJP8-0004TX-2Q for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 15:07:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjJON-00064l-O6; Thu, 21 Sep 2023 09:06:51 -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 1qjJO8-0005bR-Fy for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:06:43 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjJNq-00058e-6s for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:06:33 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0E760240103 for ; Thu, 21 Sep 2023 12:40:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695292837; bh=YInmjKxEYDJR7WQnKOh/bV1EB+8mfakahTnHyRHUGc8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=NiO/e7zqgYuhfrd8SFKZyhVd05JAJbX0QFZCfbgqPQhoebWRj2zTy8r4HlzZuyDKb kgZdInl9BftUu6Eqgi15okLKssmIWbiiYw0c9C4lb/ITHkaVHOTVsFllMboq3kxQ1j VAe/HvbjAez9Rapo8Qk7PRnoC+RxXbg5noUEFZWLJKLKh/xNnVVVKV48s+IvBFMF9U G6Z5e1TSEOb4IqVyYppCOsm/8HJa2zJj7Vs0wbtEvqz+sY8LCKKrNzp0GpIYymYDNv atUvwCWoVDjW8GulaUXKNS3EVOwXNEityNwDBX9M+33NYcII95s8/xUkH+AhdPquyC a7BJO7TERihtg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RrsPJ0y7Pz6tyd; Thu, 21 Sep 2023 12:40:36 +0200 (CEST) In-Reply-To: <83il84c3p4.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:310895 Archived-At: Eli Zaretskii writes: > Regardless of all of the above, any expensive processing that can be > divided between several execution units will take less elapsed time, > right? Not necessarily. Only when the particular algorithm used can be effectively converted into concurrent version. Sometimes, concurrent version performs worse. > ... 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? If the processing is completely independent, it is probably true. Unless overheads to create new threads are comparable with processing time (will matter for small buffers that can be process quickly). >> 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. This is... not what I know. May you please point me where in the code it is done? >From my previous experience, there separate processing of invisible property and separate processing of composition property. But not generic processing looking into all present text properties, including the ones unrelated to redisplay. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at