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

[Eli Zaretskii]

> Date: Tue, 19 Sep 2023 18:15:50 +0300
> Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 19/09/2023 17:14, Eli Zaretskii wrote:
> >> This is very simple - I suggest to not touch xdisp.c as much as
> >> possible, just make sure that it is interlocked. And focus on async
> >> support in Elisp code. Once there is async support in Elisp code, we can
> >> move further and look into xdisp.
> >>
> >> (I suggest this because I feel that xdisp is a rabbit hole we may sink
> >> in instead of doing something more productive)
> > I'm actually of the opposite opinion.  I think trying to parallelize
> > redisplay is a lower-hanging fruit, and if successful, it could bring
> > non-trivial gains to Emacs even if the rest remains single-threaded.
> 
> 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?

And there are other situations where we'd like faster redisplay, even
though they are not as bad.  For example, when a session has many
frames (I believe Stefan Monnier tends to have a lot of them in his
sessions).  To say nothing of the fact that displays become larger and
larger, and many people like to have their frames maximized.