Hello, 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. Regards, -- Nicolas Goaziou
