John Kitchin <jkitc...@andrew.cmu.edu> writes:

> I can think of two possibilities for a future approach (besides a deep dive
> on profiling the current elisp to improve the speed there). They both
> involve some substantial coding though, and would probably add
> dependencies. I am curious what anyone things about these, or if there are
> other ideas.

These are interesting ideas, but I'd rather have a deep dive on
profiling the current Elisp.

> The main point of the database was to get a query language, persistence and
> good performance. I have also used caches to speed up using bibtex files,
> and my org-contacts with reasonable performance. These have been all elisp,
> with no additional dependencies. Maybe one could do something similar to
> keep an agenda cache that is persistent and updated via hook
> functions.

If an agenda cache is required, it can be very simple. Associate entries
to agenda files. Whenever a file is modified, drop all the entries. No
need to refresh it IMO. I doubt many agenda files are modified between
two agenda calls.


Nicolas Goaziou

Reply via email to