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: Fri, 22 Sep 2023 10:05:23 +0000 Message-ID: <87pm2ay13w.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13872"; 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 Fri Sep 22 12:05:02 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 1qjd1y-0003JY-22 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 12:05:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjd1U-0004Tn-H2; Fri, 22 Sep 2023 06:04:32 -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 1qjd1O-0004P6-Fc for emacs-devel@gnu.org; Fri, 22 Sep 2023 06:04:28 -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 1qjd19-00025r-9H for emacs-devel@gnu.org; Fri, 22 Sep 2023 06:04:25 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 17D8A240103 for ; Fri, 22 Sep 2023 12:04:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695377049; bh=VDCUctf2PneRBq1SeyeeiHs6YWvs/syQ5TlrYfkBpIk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ew2m0aiUvhsdgfYwQU5wxKjQ6cN0Ln+BM2NmFyfTA8V77lQsCDh7OtssLlov/+LbQ 11jR4reZNnHB76jSs3cccjAc/F+ViAhAF3terMvhbdXyYEaFFZxSCiCFGoPCZFZBtg T91dECAvYBm7Wo8LoISf1QeE1RFdwmkPMDNvOJnhUqfqjdmc/XEkf3Sw0n3AupwdKL NSPFCcsYepbKRE2O06u9MqlVk5CAtj3fV0opyIfJ++E50vAIvAx23Cwm77ctCFFVkh 8alJ9wFlkebRL+L20fhMr27lbO+kMFM+OwUHWLf5ehMv4LgLuxdQGCtM+/xm/QAgg2 k0yXSx+WzumqA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RsSXl5QMlz6v3x; Fri, 22 Sep 2023 12:04:07 +0200 (CEST) In-Reply-To: <831qerac81.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:310944 Archived-At: Eli Zaretskii writes: >> This is... not what I know. May you please point me where in the code it >> is done? > > 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). 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. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at