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

[Dmitry Gutov]

On 19/09/2023 20:54, Eli Zaretskii wrote:
> > Date: Tue, 19 Sep 2023 19:01:31 +0300
> > Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > > > Do we have evidence that the speed of redisplay is a limiting factor in
> > > > general Emacs usage? I.e. with an optimized build and most of the
> > > > popular modes (excepting certain display-heavy Org buffers, let's say).
> > > You already forgot the long-lines problems?
> >
> > The long-lines problem wasn't solvable with parallel redisplay either,
> > it was a case of high algorithm complexity (a combination of them).
>
> 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.

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

> 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.

When I asked the question, I was under the impression that people do 
have some data to point this way, and I just missed it.

> 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).

I'm not saying it is necessary, but it is a good idea, I think.

> The right time to ask the questions you are asking is when a more or
> less detailed design is presented, and we can assess the complexity
> and other possible downsides of the proposal against its gains, if
> any.  We are not there yet.  Let's keep our minds open and see where
> this leads us, okay?

Sure.