Re: How to make agenda generation faster

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Adam Porter <adam@alphapapa.net> writes:

> My feedback is: there be dragons.  ;)  The Agenda code is very
> complicated and hard to follow, and it's hard to optimize something that
> is hard to understand.

And hard to maintain. We should really do something about it.

> In the long run, to get significant speed improvements, I think it may
> be necessary to reimplement the Agenda.

Agreed.

> However, due to the nature of it (i.e. regexp searches through buffers
> to find entries), I don't know how much faster it can be made. I don't
> mean that I doubt it can be--I mean that, truly, I don't know, because
> it's hard to understand the flow of the code.
>
> I think that it is already fairly well optimized, given its limitations.
> However, an example of a potential improvement would be to refactor it
> to work with lexical-binding enabled (which didn't exist when it was
> first created); I can't say how much of an improvement it would make,
> but my understanding is that code that runs with lexical-binding enabled
> is generally faster.

Not really. But it's certainly easier to understand since it removes one
class of problems.

> But doing that would be a non-trivial project, I
> think, requiring the fixing of many inevitable regressions in the
> process.
>
> If you haven't seen them already, you may find my org-ql and
> org-ql-agenda code useful.  org-ql-agenda presents an Agenda-like
> buffer.  N.B. It does *not* implement most of the Agenda features, but
> it does emulate an Org Agenda buffer by setting the appropriate text
> properties on entries and formatting them in a similar way.

Instead of re-inventing the wheel, or putting efforts into a wheel-like
invention, wouldn't it make sense to actually work on Org Agenda itself?

I didn't look closely at org-ql, but I had the idea of splitting the
Agenda in two distinct parts. One would be responsible for collecting,
possibly asynchronously, and caching data from Org documents. The other
one would provide a DSL to query and display the results extracted from
the output of the first part. The second part could even be made generic
enough to be extracted from Org and become some part of Emacs.
Displaying filtered data, maybe in a timeline, could be useful for other
packages. Unfortunately, I don't have time to work on this. Ah well.

So again, wouldn't it be nice to think about Org Agenda-ng?

Regards,

-- 
Nicolas Goaziou