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: Fri, 22 Sep 2023 16:01:33 +0300 Message-ID: <8334z6745u.fsf@gnu.org> References: <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> <87pm2bzu33.fsf@localhost> <831qerac81.fsf@gnu.org> <87pm2ay13w.fsf@localhost> <83o7hu77bm.fsf@gnu.org> <87wmwiwey6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16391"; 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 Fri Sep 22 15:02: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 1qjfnU-00043r-Rv for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 15:02:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfmp-0004Tj-6e; Fri, 22 Sep 2023 09:01:35 -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 1qjfmo-0004TU-66 for emacs-devel@gnu.org; Fri, 22 Sep 2023 09:01:34 -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 1qjfml-0000qE-3A; Fri, 22 Sep 2023 09:01:31 -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=htctBbWxb6LQ+DtGj8AnF/PYRbQo/6SSE/5WetmstJA=; b=ridFJP3hdVXx GFXTk7nbkjk/RleEtYC3/l62rVJpFKZGhZ8GQpMZ/a3FKPvayPF4vBq0nlcXtivpqy3pNLY0Miaon UrU8Ybd2oXd6KxXXq31HIyl3gdiF6dvriKsLFDJGK10bP96aT9THR82mzEDT/nMJGY5VhKTwQ/l+g umYjRF1ok7f0zp9C/Ctl3phIwd6Em/oM3eZ4wB1eigqGMHJ/oCvwmUPdPXWQC0rl9LWysqacqTZIe aKz+JgcqJyiJ6HRj9GcP296Aaph/09WPfjqPjo/+crxk7YiT40qkSFTwC5HYD4G0++JbPxH1IYyin gT6pGfh6ICK6/J8jpXiW/w==; In-Reply-To: <87wmwiwey6.fsf@localhost> (message from Ihor Radchenko on Fri, 22 Sep 2023 15:49:21 +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:310959 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Fri, 22 Sep 2023 15:49:21 +0300 > > > Feel free to present such a more efficient algorithm, and thanks. > > And I'm not sure I understand why you think that > > > > min (mapcar (Fnext_single_property_change, it_props)) > > > > will be cheaper than the current algorithm in compute_stop_pos, since > > Fnext_single_property_change basically examines the same intervals > > again and again for each property in it_props. > > The algorithm I have in mind is to change interval tree to store several > trees together - a common tree storing segments delimited by _a_ > property change + a tree for individual properties. That way, looking up > for next single property change will be a simple call to next_interval for > the property itself + property aliases. Feel free to implement that and benchmark it against the current implementation. If it's significantly faster, I';m sure we will accept the changes. Thanks.