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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>