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

[Dmitry Gutov <dmitry@gutov.dev>]

On 20/09/2023 14:28, Eli Zaretskii wrote:
>> Date: Tue, 19 Sep 2023 23:21:46 +0300
>> Cc: yantar92@posteo.net, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 19/09/2023 20:54, Eli Zaretskii wrote:
>>>
>>> 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.
> 
> You are considering only the redisplay of that single window which has
> long lines.  But what about the other windows, which perhaps don't
> have long lines?  And what about the main thread of Emacs itself,
> which freezes for as long as redisplay didn't finish, thus preventing
> user interaction and responsiveness in general?  These factors should
> not be neglected.

Splitting an N^3 program in two to run in half the time won't make it 
have adequate performance. When the problem is algorithmic, we'll have 
to fix it as such.

>> But I think we've much improved on the issue by reducing the complexity
>> instead (correct me if I'm wrong here).
> 
> If you mean the long-lines improvements in Emacs 29, then we traded
> off correctness in at least some cases.  It wasn't for free.

I see.

Well, we definitely did that WRT to font-lock (the part which we might 
tweak or roll back in the future). I wasn't sure if that's also what 
happened in the deep of the display engine as well.

>>> 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.
> 
> With enough text properties and overlays, you can definitely see a
> tangible slowdown in frame rate.  E.g., Org developers don't want to
> use text properties because they slow down redisplay, and thus they
> consider them not scalable enough.
> 
>>> 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).
> 
> On the high-level design level, it should be clear without any need
> for benchmarking that separating redisplay from the main thread could
> bring benefits.  Isn't that what every GUI application out there does?
> So trying to think about that is always a good thing, IMO.

Okay, here's a question that I should have started with: what kind of 
parallelism are we discussing?

A) Initially I figured it's the ability to render a single window using 
multiple threads of execution. It's the one my mind immediately went to, 
but might the hardest of the bunch because it would require us to 
parallelize the display algorithm for a single buffer.

B) Being able to render different windows/buffers fully in parallel. I 
think that requires us to implement concurrent Lisp threads, at the very 
least. That's likely to drag down the single-thread performance (though 
it's hard to predict by how much).

C) Having only a separate (not Lisp) thread for GUI might help with 
responsiveness somewhat (by throttling certain expensive windows down, 
for example), but overall it might not improve by much. Though I suppose 
it could render in parallel those buffers which don't need to run Lisp 
to display? Anyway it would be synchronized to the one Lisp interpreter.