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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> May you point to the xdisp.c function that is being slow?
>
> The basic iteration and layout calculations are slow because (a) they
> must examine every character between point A and point B to figure out
> the relative position of these points on the screen, and (b) because
> this examination can only go forward, not back (so to go back, we must
> "jump" very far back, and then go forward).

In other words, processing a single window is being slow.
The question now is whether processing the whole window can be split
into multiple independent chunks. If it can, such processing can run in
parallel.

>> Ok. But is it possible to redisplay the whole frame without ever calling Elisp?
>
> Probably not "without ever", but why is it important in this context?
> Most of the processing is in C, not in Lisp.

My point is that any time we have to run Lisp during redisplay, without
async Elisp threads, we have to acquire global lock first, which will
degrade concurrency. I am not sure how bad the degradation will be.

>> Again, not always. I do not think that the _initial_ goal should be
>> making every aspect of Elisp working asynchronously without
>> interlocking. We certainly want all Elisp to work in threads, possibly
>> with global lock. But if we get at least some part of useful Elisp to
>> run truly concurrently, it will already be a win.
>
> Not if we want to run the existing Lisp programs in threads with
> minimal or no changes.  Because Lisp programs we have now require
> display and user interaction all the time, whether by themselves or by
> lower-level subroutines they call.

Sure. _existing_. What I have in mind is programs specifically written
to take advantage of concurrency. Just to address common performance
bottlenecks.

>> I think you misunderstood. I did not mean calling GNU grep. I meant
>> calling M-x grep - Elisp code searching across many Emacs buffers. It
>> would be useful if such code could run concurrently.
>
> It will be much more useful if it could also show the hits as it runs,
> instead of requiring the user to wait till it finishes.

Maybe. But reducing the overall waiting time at the cost of not seeing
the progress is an OK compromise, IMHO.

>> Another example is org-agenda that is running a large number of regexp
>> search across many buffers. Some real-world users search across as many
>> as 500 buffers, with results accumulated into agenda. It would certainly
>> be useful to run that regexp search concurrently, in multiple buffers at
>> once. Or maybe even on several regions of a single, large buffer.
>
> And you never want to show the accumulated agenda as it is
> accumulated?

Yes. Because part of the fontification is performed at the very end,
when everything is accumulated.

>> I agree here. But do note that the interest (and some trial code by Po
>> Lu) so far has been focused on Elisp threads.
>
> I'm quite sure people who disregard the display when they are talking
> about concurrent Lisp threads are going to repeat the same mistake we
> made with the existing Lisp threads.  We must learn from past
> experience if we want to succeed.

What about addressing the existing problems with cooperating Lisp
threads then?

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