emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Tue, 19 Sep 2023 19:01:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 19/09/2023 18:37, Eli Zaretskii wrote:
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?

The long-lines problem wasn't solvable with parallel redisplay either, it was a case of high algorithm complexity (a combination of them).

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.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]