[Top][All Lists]

[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 23:21:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

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?


reply via email to

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