From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: Is there a way to get all agenda TODOs programmatically? Date: Wed, 03 Jan 2018 08:16:44 -0600 Message-ID: <87lghft4c3.fsf@alphapapa.net> References: <87376v36up.fsf@mbork.pl> <87a813rqdx.fsf@fastmail.fm> <87r2ue29j8.fsf@mbork.pl> <874lrasxu2.fsf@fastmail.fm> <877et5joln.fsf@mbork.pl> <87shbqv58k.fsf@alphapapa.net> <87vagjffuq.fsf@mbork.pl> <87vagjtgom.fsf@alphapapa.net> <878tdff3x6.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWjqq-00029c-LR for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 09:17:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eWjql-0003ba-P8 for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 09:17:04 -0500 Received: from [195.159.176.226] (port=52369 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eWjql-0003aj-Hv for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 09:16:59 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eWjoj-0008Ei-91 for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 15:14:53 +0100 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: emacs-orgmode@gnu.org Nicolas Goaziou writes: Hi Nicolas, > I don't think the size of the functions matter much. Agenda is optimized > for single day view, so it is fast in this case because it only looks > for "interesting" headlines. However, this mechanism is terrible for > multi-days agendas: Agenda treats them as multiple single days agendas, > so you end up looking again and again at the same entries. Yes, when I discovered that, I was very surprised that multi-day agendas are as fast as they are! >> An idea I had recently was to make more use of inline functions, >> defsubst, etc, to avoid that. It might let us make the code more >> functional while letting the byte-compiler optimize it. At the same >> time, I wonder why it isn't already that way--maybe better Emacs >> programmers know why it wouldn't be a good idea. > > Usually, you inline a function if you are certain funcall overhead is > responsible for the slowness. Thanks. I checked my notes again, and I see that funcall overhead was not actually the issue (at least, I hadn't gotten far enough for it to be). The problem was that org-element-parse-buffer was very slow in comparison, since it parses the entire buffer rather than, as you said, just interesting parts. So I'm trying another approach that doesn't parse the whole buffer, which seems to show promise...