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.