Primary examples would be adding a note (CTRL-z) or changing a tag on a person and then having org-agenda update that. I am assuming it is because the entire file needs to be parsed rather than say, some index of entries.
(so perhaps I mischaracterized org-contacts as being slow versus its interaction with other programs.) (for search I use swiper which is very efficient for searching the file whenI need it.). tho quite interested in seeing what perf enhancements you've done on large org files would be interesting. Daryl. PS> As an outside feature though, interoperability of the org-contact formats with other operating system address books, most notable gnome contacts/evolution, goog contacts, and OSX address book would be high on my list in terms of improving org-contacts though. (eg, raw, structued info in all address books, and say perhaps notes or similar maintained and synced in ome manner. On Mon, Sep 7, 2020 at 10:27 AM Ihor Radchenko <yanta...@gmail.com> wrote: > > However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > Could you provide some examples what exactly is being slow? > Maybe my WIP work on improving performance on large org files [1] might > help. > > Best, > Ihor > > [1] https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127740.html > > > Daryl Manning <dwm+orgm...@wakatara.com> writes: > > > Strangely, I've come to rely over the last year on org-contacts as a > > lightweight, taggable CRM. However, as the file and C-z notes have grown, > > performance has really started to drag. I know people have used various > > schemes (caching) etc to try to improve performance and the like, but > > updates to the file are taking a solid 5 seconds now when making major > > updates and moving tags around. > > > > Is there a solid, forked branch anywhere that focuses on enhancing > > performance anywhere? I'm tempted to wade in and add features and > > improvements myself but my elisp-fu is dodgy at best (more golang these > > days.). > > > > I'd be interested in what people are doing to speed it up (and if it is > > under anything like active development for improvements. It does feel > super > > handy, and feels like it just needs a performance and more modern > features > > overhaul - more on interoperability and less on in-emacs > interoperability.). > > > > Would love to hear what people have done overall workflow wise if they > are > > using it seriously. > > > > thanks, > > Daryl. >
