Ihor Radchenko <yanta...@gmail.com> writes:

>>> Asynchronous code is not faster; it's generally slower because of
>>> yielding and synchronization.
>
>> Anyway, I will try to throw yields into agenda code just to check how
>> bad the performance can degrade.
>
> With the following code, org-agenda-redo runs for 21 second on my
> system, while without threads it is 16 seconds. However, emacs remains
> responsive during rebuilding agenda!
>
> (define-advice org-agenda-redo (:around (oldfun &optional all) make-async)
>   (make-thread (lambda () (funcall oldfun all)) "org-agenda-redo"))
> (define-advice org-agenda-skip-eval (:around (oldfun form) make-async)
>   (thread-join (make-thread (lambda () (funcall oldfun form)) 
> "org-agenda-skip-eval")))

That's a very elegant way to add the threading!  The performance penalty
is noticeable, but the tradeoff could be worth it in some cases, like a
background agenda refresh on a timer, or after a "remote" edit.  I can
imagine an org-agenda-refresh-async command that would add that advice
and remove them in an unwind-protect.

> The problem, of course, is that touching agenda buffer and org buffers
> may be risky while org-agenda-redo is running.
> Wondering if it is possible to block user commands during that time.

The first thing that comes to mind is to set buffer-read-only on each
buffer before it is scanned, and unset it when done with a buffer.  That
might not be doable with advice.


Reply via email to