From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: [Orgmode] Slow speed of week and month views Date: Fri, 04 Aug 2017 22:07:55 -0500 Message-ID: <878tiyr9tg.fsf@alphapapa.net> References: <87efsre565.fsf@grothesque.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddpRj-0008Nn-J5 for emacs-orgmode@gnu.org; Fri, 04 Aug 2017 23:08:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddpRg-0000xA-AM for emacs-orgmode@gnu.org; Fri, 04 Aug 2017 23:08:11 -0400 Received: from [195.159.176.226] (port=38410 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddpRg-0000wR-3h for emacs-orgmode@gnu.org; Fri, 04 Aug 2017 23:08:08 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ddpRV-0002KH-TX for emacs-orgmode@gnu.org; Sat, 05 Aug 2017 05:07:57 +0200 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 Christoph Groth writes: > Carsten Dominik wrote in 2010: > >> I am afraid I don't see any major speed improvements that could make >> this happen. Yes, one could parse all the files once, build a table >> in memory and get the entries for each day from there - >> but that comes down to a complete rewrite of the parser, maybe even >> to switching to an internal representation model for Org-mode. > >> I don't see that happening, I am afraid. Wow, you must have done some digging to find that, Christoph. :) > Computing the agenda month view takes 20 seconds in my case. That's > perhaps the most serious problem with orgmode as I (and I suppose > others as well) use it. It would be great if this issue could be > solved after all. > > Would it be really so difficult to do? The actual parsing seems to be > done in the function org-agenda-get-day-entries as called by > org-agenda-list. Inside org-agenda-get-day-entries the crucial bit > seems to be (org-agenda-today-p date). If that bit got replaced by > something that matches more than a single day, wouldn't this mostly do > the trick? > > This is much easier than "rewriting the parser", so it seems that I'm > overlooking some problems. I think Carsten is correct that it would require significant new code. I looked at the code you mentioned, but I think you missed the bigger structure. org-agenda-list first builds a list of day numbers from the span that is set, then it calls org-agenda-get-day-entries for each day number. The (org-agenda-today-p date) form in org-agenda-get-day-entries is only checked when the function is getting TODO items, and then it calls org-agenda-get-todos to actually get the entries. And as far as I can tell, org-agenda-list doesn't set the :todo selector at all, so the org-agenda-get-todos function isn't called when building a time-based agenda view; instead it's called for the org-todo-list command. This seems to be confirmed by the docstring for org-agenda-entry-types, which doesn't indicate that :todo is allowed as a type for daily/weekly agendas. I'm not as expert as Carsten or any of the current maintainers, but a possible way to speed up agenda creation for longer time spans would be to avoid parsing files repeatedly. IIUC they are parsed once for every date shown in the agenda. Instead, if they were parsed once and returned a list of items that was filtered or grouped once, that would probably be faster. But doing that would, as Carsten said, require rewriting a lot of code. Essentially you'd be creating a new agenda system, so you'd have to reimplement a lot of existing code. You could do it in parallel, rather than replacing existing code, so you wouldn't have to break the existing agenda system. But I don't think there's any way to shortcut writing the new system. I don't think there's any "low hanging fruit." Anyway, something based on org-map-entries might be interesting, but it's hard to say if it would actually be faster in the end.