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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Without having Elisp async threads, what you suggest is only possible
for the non-Elisp parts of the redisplay.

May you list which C-level parts of the redisplay are known to be slow?

AFAIU, long-lines performance is largely problematic when running Elisp.
(Also, isn't it solved already?)

Another one you mentioned is displaying many frames. But isn't it
optimized by the part of the code that delays redisplay of frames that
are not visible? Or does Stefan (or anyone) tend to have so many
_visible_ frames?

>> I am particularly worried about scenarios when window geometry changes
>> by asynchronous threads. Or, say, face definitions. Imagine that it
>> happens at point when we are already drawing the now obsolete geometry
>> onto glass?
>
> xdisp.c has solutions for these two (and other similar) situations.
> The problems have nothing to do with parallelism, they happen today
> because we call Lisp at certain places in the display engine.

Yes, but now we know exactly in which segments of the code the geometry
might change. And check for it in strategic places.

In the case of asynchronous threads, the geometry may change any time
(when another threads happens to run something that affects geometry),
which is not accounted for by the current code.

>> > We tried that already, with the existing Lisp threads.  One reason why
>> > those are almost never used is that the display issue was left
>> > unresolved.
>> 
>> That might be one reason, but not the only reason. And certainly not the
>> most important reason for the use cases where I did try to use threads
>> myself.
>
> There's more than one reason, that's true.  But it doesn't change the
> fact that all those problems have to be resolved before we have
> reasonably usable threads.

I disagree. Yes, _all_ the problems are to be solved eventually. But
solving _some_ of the problems will already be an improvement. IMHO, it
is not all-or-nothing; we can split the problem into several
sub-problems and solve them one by one.

>> As we discussed previously, a number of Elisp programs can benefit from
>> async threads even when redisplay is not asynchronous - network queries
>> (gnus), text parsing (org-mode, slow LSP server communication, xml
>> processing).
>
> You forget that almost every Lisp program in Emacs either displays
> something or affects stuff that affects redisplay.  It's easy to
> forget, I know, because in Emacs redisplay "just happens" by some
> magic.

I don't forget that. However, we do not have to make each and every
thread _fully_ asynchronous. It is often enough to process the
performance bottlenecks asynchronously. After that processing, we can go
ahead and present the results synchronously to user.

Let me provide a more concrete example.
Consider something as simple as grepping across project files.
The process of grepping involves: (1) opening and searching many files;
(2) presenting results to the user. Stage (1) does not really involve
user interaction or redisplay and can greatly benefit from asynchronous
threads - we can simply search multiple files at the same time. Then,
even if stage (2) has to be synchronous, it does not matter - stage (1)
is what takes most of the time and makes the user wait.

>> To be clear, it would indeed be nice to have async redisplay.
>
> I'm not talking about async redisplay, I'm talking about the ability
> of non-main threads to display something or do something that would
> cause redisplay change the stuff on the glass.

Then, how will it be possible without first having async Elisp threads?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>