From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: How to make agenda generation faster
Date: Wed, 17 Oct 2018 15:01:50 +0200 [thread overview]
Message-ID: <87pnw8engh.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87ftx5fx3n.fsf@alphapapa.net> (Adam Porter's message of "Tue, 16 Oct 2018 15:35:56 -0500")
Hello,
Adam Porter <adam@alphapapa.net> writes:
> From what I've read, the byte-compiler can optimize better when
> lexical-binding is used.
It can, but AFAIK, it doesn't yet. It also means un-optimized lexical
binding may be slightly slower than dynamic scoping for the time being.
> I've thought about this for a while. It seems to me that the issue is
> that Org buffers are, of course, plain-text buffers. There is no
> persistent, in-memory representation other than the buffer, so whenever
> Org needs structured/semantic data, it must parse it out of the buffer,
> which is necessarily rather slow. If there were a way to keep an
> outline tree in memory, parallel to the buffer itself, that would allow
> operations like search, agenda, etc. to be greatly sped up.
I don't think that's necessary. File caching as you suggest below, can
go a long way. Filling cache during idle time, too.
> But how would that work in Emacs? Theoretically, we could write some
> code, applied on self-insert-command, to update the "parallel tree
> structure" as the user manipulates the plain-text in the buffer
> (e.g. add a new node when the user types a "*" to create a new heading),
> and also apply it to functions that manipulate the outline structurally
> in the buffer. But, of course, that sounds very complicated. I would
> not relish the idea of debugging code to keep a cached tree in sync with
> a plain-text buffer outline. :)
My over-engineering-o-meter flashes red, too.
> Anyway, org-ql tries to do some of what you mentioned. It does
> rudimentary, per-buffer, per-query caching (as long as the buffer is not
> modified, the cache remains valid), which helps when there are several
> Org files open that are referred to often but not as often modified.
That's what I did in an agenda upgrade I tried a few months ago.
Unfortunately, caching is not compatible with the underlying logic of
current Agenda, in particular with `org-agenda-skip-function'.
> And the query and presentation code are separated (org-ql and
> org-ql-agenda).
That's a very good thing.
> I don't know how widely it's used, but the repo is getting some regular
> traffic, and I'm using it as the backend for my org-sidebar package.
> I'd be happy if it could be made more generally useful, or if it could
> be helpful to Org itself in some way. Contributions are welcome.
That's not exactly what I'm suggesting. I suggest to move the work in
Org tree, e.g., as an org-agenda-ng.el library, and, from there,
implement back most of the features of the current agenda.
Org cannot really benefit from libraries living outside Emacs, as we
recently learnt with htmlize issue.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2018-10-17 13:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-07 4:53 How to make agenda generation faster Marcin Borkowski
2018-10-08 7:20 ` Michael Welle
2018-10-10 20:03 ` Marcin Borkowski
2018-10-10 21:01 ` Samuel Wales
2018-10-11 6:48 ` Michael Welle
2018-10-11 8:48 ` Marcin Borkowski
2018-10-11 19:59 ` Samuel Wales
2018-10-14 8:51 ` Marcin Borkowski
2018-10-09 6:37 ` Adam Porter
2018-10-09 16:11 ` Nicolas Goaziou
2018-10-10 20:01 ` Marcin Borkowski
2018-10-16 20:35 ` Adam Porter
2018-10-17 7:04 ` Ihor Radchenko
2018-10-17 13:01 ` Nicolas Goaziou [this message]
2018-10-17 19:12 ` Adam Porter
2018-10-18 22:48 ` Nicolas Goaziou
2018-10-19 0:04 ` stardiviner
2018-10-20 2:12 ` Adam Porter
2018-10-20 8:12 ` Nicolas Goaziou
2018-10-10 19:59 ` Marcin Borkowski
2018-10-09 11:47 ` Julius Dittmar
2018-10-10 20:03 ` Marcin Borkowski
2018-10-11 6:40 ` Michael Welle
2018-10-14 7:42 ` Marcin Borkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pnw8engh.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).