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

[Eli Zaretskii <eliz@gnu.org>]

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

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?

> It would help to see some info on:
> 
> - Whether Stefan's build is optimized,
> - How much time the many-frames case spends talking to the windowing 
> system, compared to the time our redisplay takes internally. If there 
> are many frames displayed, but the current buffer is shown in only one 
> of them (or two, etc), then shouldn't the rest of the frames stay mostly 
> still anyway?
> 
> I also like to have my frames maximized, and I have a 4K display -- even 
> so, redisplay seems to be mostly fine (with 1-2 frames anyway). But 
> rendering large windows at high resolution, while it can be taxing, 
> generally bottlenecks at something else than the layout algorithms. 
> Unless you're arguing that the layouts are going to become more complex 
> exponentially as well.

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.

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?