Domanda : Perché la org-map-entries
corrispondenza delle proprietà è così lenta e cosa posso fare per accelerarla?
Background : ho un uso relativamente semplice per org-map-entries
: afferrare lo sforzo (in minuti interi) da tutte le voci dell'agenda dell'organizzazione con tag goal
e una data priorità (ad es B
.).
(org-map-entries
#'hw-org-get-effort-in-minutes
"goal+PRIORITY=\"B\""
'agenda)
Questo è terribilmente lento, impiegando più di un minuto per il mio file dell'agenda della linea ~ 12k.
Tuttavia, se rimuovo il PRIORITY
filtro dal filtro in modo che qualsiasi goals
elemento taggato sia selezionato, si completa quasi istantaneamente.
Posso anche impostare filtri come goal/DONE
e si completano molto rapidamente, ma se faccio qualcosa del genere goals+EFFORT>0
, torniamo a prendere più di un minuto. Sembra che le proprietà in generale siano molto lente da abbinare.
Ho trovato una soluzione cheat : posso abbinare le proprietà all'interno della funzione mappata molto rapidamente usando org-entry-get
. Quando lo faccio, l'esecuzione è meno di un secondo. Sembra sciocco, speriamo che ci sia un modo migliore, ma almeno funziona!
Già provato : dai (benchmark 1000 (hw-org-effort-to-minutes "1:20"))
ritorni "Elapsed time: 0.000019s"
, non credo che la mia funzione contribuisca molto.
Secondo profiler
, viene utilizzato ~ 40% del tempo CPU cond
, con ~ 29% proveniente dall'analisi dell'elemento ( org-element--current-element
). I prossimi due maggiori contributi complessivi sono il 14% e il 13%, quindi il 40% cond
sembra essere la maggior parte del problema. Non sono sicuro del motivo per cui l'analisi dell'elemento verrebbe eseguita più spesso con gli abbinamenti delle proprietà, a meno che la differenza non derivi dall'analisi solo dell'intestazione (tag, TODO) rispetto all'intestazione + corpo (proprietà).