From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ihor Radchenko Subject: Re: Asynchronous org-agenda-redo Date: Sun, 22 Dec 2019 14:54:11 +0800 Message-ID: <87fthcrgto.fsf@gmail.com> References: <87k172ot2m.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87pngtsppt.fsf@alphapapa.net> <87o8wda6nv.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87h824sos5.fsf@alphapapa.net> <87wob0fwsg.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87immk8szl.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <878snfsdt7.fsf@alphapapa.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42966) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iivA2-0002oG-7w for emacs-orgmode@gnu.org; Sun, 22 Dec 2019 01:56:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iivA1-0007Op-05 for emacs-orgmode@gnu.org; Sun, 22 Dec 2019 01:56:18 -0500 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:42804) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iivA0-0007JA-ON for emacs-orgmode@gnu.org; Sun, 22 Dec 2019 01:56:16 -0500 Received: by mail-wr1-x434.google.com with SMTP id q6so13356925wro.9 for ; Sat, 21 Dec 2019 22:56:16 -0800 (PST) In-Reply-To: <878snfsdt7.fsf@alphapapa.net> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Adam Porter , emacs-orgmode@gnu.org > That's a very elegant way to add the threading! Thanks for kind words. > 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. That may be a good way to go. Probably, even refreshing agenda in a separate copy of agenda buffer, so that the current version remains usable. > 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. This is not enough. If you accidentally move the point in the buffer being processed by agenda, the results may be unpredictable (org-agenda-get-* functions move across the buffer with re-search-forward). Any ideas how to deal with this? Best, Ihor Adam Porter writes: > Ihor Radchenko 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. > >