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 14:53:17 +0300 Message-ID: <83o7hu77bm.fsf@gnu.org> References: <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> <87pm2bzu33.fsf@localhost> <831qerac81.fsf@gnu.org> <87pm2ay13w.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21252"; 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 13:54:10 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 1qjejZ-0005Ia-5m for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 13:54:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjeig-0003sT-8j; Fri, 22 Sep 2023 07:53:14 -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 1qjeie-0003r3-IV for emacs-devel@gnu.org; Fri, 22 Sep 2023 07:53:12 -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 1qjeib-0001gc-LC; Fri, 22 Sep 2023 07:53:09 -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=YoycgVLhj2RE0MXDlEh+4xVA6j7RN/fAhwM8TjL8hZ4=; b=NGn42tKSn974 4Lcn9gOYi6Ne8uhaBZoFdWo0w/DSh5sF+mGDxvjrWKw49DMK1WKn6pj17z+yLAxZJIfYIsZDHbKU6 AkNsRTuhTgZ+L3jpgjJym9t7y5iwW87pJ3GxrJCDP4/BFOd0AMB+N3QYzJzOXjnxd5CUMfCrJjJoG xHYQJrhXZyb+wQpS6oIK23pcV8J+0usb7e4kqnnrdxO57kj/kA19tHXiByRk4CkVS8fTjtmptxJYu mfaYPJGZA7LJgffyCAgoi0S/BGNER5QTYBcInuks6+9sAV+jqTWPMQGrTBDIsUcFZF9JVchSykGqh awRSQZWmuSIT/97/+iIP5g==; In-Reply-To: <87pm2ay13w.fsf@localhost> (message from Ihor Radchenko on Fri, 22 Sep 2023 10:05:23 +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:310950 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Fri, 22 Sep 2023 10:05:23 +0000 > > Eli Zaretskii writes: > > > compute_stop_pos finds the next "stop position" where properties (or > > something else of interest to redisplay) change, and when the > > iteration gets to that position, handle_stop calls the available > > handler methods to do their thing. The intervals of the text > > properties are examined by compute_stop_pos. > > Thanks! > "stop position" is not triggered by _all_ the properties though. > `compute_stop_pos' calculates the largest region where the properties > listed in `it_props' ('fontified, 'face, 'invisible, and 'composition) > remain the same. If any other property not in the list changes, it is > ignored (except `char-property-alias-alist' which may link other > properties to 'fontified/face/invisible/composition). Does this contradict what I wrote? if so, how? > Further, handle_stop handlers do search for their corresponding handled > property via Fnext_single_property_change, which again iterates over > every interval in the buffer until that single property value changes. If they do this, it's because they need that to do their thing. There's no requirement from the handlers to do that. Moreover, we could record the position of the next change of each property, when the handler does determine that, and use that in compute_stop_pos, to avoid repeating the same search. > IMHO, one of the bottlenecks with the current implementation is that we > have to iterate over unrelated properties to find the position of > interest. So, redisplay performance is not just affected by the > properties that matter, but by _all_ properties in buffer (strictly > speaking, by all the intervals in buffer). > > I believe that having a more efficient algorithm to detect where a > single property change should speed things up significantly. handle_stop > will benefit directly, while `compute_stop_pos' could query > min (mapcar (Fnext_single_property_change, it_props)) > to avoid counting unrelated properties. 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.