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

[Eli Zaretskii]

> Date: Tue, 19 Sep 2023 23:21:46 +0300
> Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 19/09/2023 20:54, Eli Zaretskii wrote:
> > 
> > How do you know that parallel redisplay will not solve this?  This can
> > only be obvious when the detailed design of that is presented.  Until
> > then, it's anyone's guess.
> 
> It's not 100%, but seems logical: the problem with long lines is that 
> displaying a single line took non-linear amount of time proportional to 
> its length. To be able to layout it in parallel, we would somehow have 
> to be able to split it into independent pieces (perhaps using some 
> caching mechanism?, IDK). If we are actually able to do that (which 
> seems difficult), a non-parallel redisplay algorithm should happily use 
> the same mid-line checkpoint information to work on smaller pieces of 
> the line, likewise increasing the speed.

You are considering only the redisplay of that single window which has
long lines.  But what about the other windows, which perhaps don't
have long lines?  And what about the main thread of Emacs itself,
which freezes for as long as redisplay didn't finish, thus preventing
user interaction and responsiveness in general?  These factors should
not be neglected.

> But I think we've much improved on the issue by reducing the complexity 
> instead (correct me if I'm wrong here).

If you mean the long-lines improvements in Emacs 29, then we traded
off correctness in at least some cases.  It wasn't for free.

> > Anyway, you asked for evidence that redisplay could benefit from
> > performance boost, and I gave you some.  Now you for some reason want
> > to claim that my evidence doesn't convince you, but it still is
> > evidence, right?
> 
> I was looking for other examples, to be honest. Like, for example, 
> evidence that redisplay is something that keeps an average Emacs session 
> from running at 60fps. Or even at 30fps. That would make it a bottleneck.

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.

> > You seem to be opposed to attempts to explore ways of making Emacs
> > less single-threaded than it is today, unless someone provides a
> > proof, up front, that this will necessarily solve some particular
> > problem?  Why? what harm could that possibly do, if it succeeds?  And
> > if it doesn't succeed, at least we will have learned something
> > probably useful for the future.
> 
> It is my experience that good benchmarking often helps with changing the 
> design as well. Or coming up with a new one (there are a lot of options 
> for how one could proceed).

On the high-level design level, it should be clear without any need
for benchmarking that separating redisplay from the main thread could
bring benefits.  Isn't that what every GUI application out there does?
So trying to think about that is always a good thing, IMO.