4

Question: Why is org-map-entries property matching so slow, and what can I do to speed it up?

Background: I have a relatively simple use for org-map-entries: grab the effort (in integer minutes) from all org agenda entries with tag goal and a given priority (e.g. B).

(org-map-entries #'hw-org-get-effort-in-minutes "goal+PRIORITY=\"B\"" 'agenda)

This is terribly slow, taking over a minute for my ~12k line agenda file.

However, if I remove the PRIORITY from the filter so any goals tagged item is selected, it completes almost instantly.

I can also set filters like goal/DONE and they complete very quickly, but if I do something like goals+EFFORT>0 we are back to taking over a minute. It seems properties in general are very slow to match.

I found a cheat workaround: I can match properties inside the the mapped function very quickly using org-entry-get. When I do this, execution is less than a second. This seems silly, hopefully there is a better way, but at least it works!

Already tried: Since (benchmark 1000 (hw-org-effort-to-minutes "1:20")) returns "Elapsed time: 0.000019s", I don't think my function contributes much.

According to profiler, ~40% of CPU time is used by cond, with ~29% coming from element parsing (org-element--current-element). The next two largest contributions overall are 14% and 13%, so the 40% of cond seems to be the bulk of the problem. Not sure why element parsing would be done more often with property matchers, unless the difference comes from parsing only header (tags, TODO) vs. header + body (properties).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.