Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> 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 <eliz@gnu.org> 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.