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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>, acm@muc.de, incal@dataswamp.org,
>  emacs-devel@gnu.org
> Date: Wed, 20 Sep 2023 11:38:00 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > With enough text properties and overlays, you can definitely see a
> > tangible slowdown in frame rate.  E.g., Org developers don't want to
> > use text properties because they slow down redisplay, and thus they
> > consider them not scalable enough.
> 
> I do not think that it needs be addressed by async threads.
> The main problem with text properties, AFAIK, is that segment tree Emacs
> uses makes searching for next single property change scale with the
> total number of segments where _any_ arbitrary property changes, not
> with actual number of that searched property segments.

Regardless of all of the above, any expensive processing that can be
divided between several execution units will take less elapsed time,
right?  So, for example, processing text properties of two buffers
sequentially by the same thread (as this is done now) will take longer
than processing them concurrently in parallel, right?  So redisplaying
two windows by two independent threads running concurrently on two
execution units will be faster, right?

> I believe that it is more a question of rewriting text property handling
> into multiple segment trees dedicated to individual properties.

Not as far as redisplay is concerned, no.  The display engine _wants_
to look for the next change in any text property, because it processes
them all "together".  That is, it finds the buffer position where any
of the text properties change, then hands that position to each of the
known methods for handling property changes so that each one of them
does its thing.