On 03/03/2021 09:34, Samuel Wales wrote:
until recently in maint, ido and ido hacks with both refile and refile
goto [note: org-refile with a goto arg, not org-goto] has worked
perfectly. with no cache. now, there is an issue, where with no
cache that i know of, the first use, or the first use in a long time,
will actually present a huge file list that includes crazy elements
and is not constrained by even the verify function.
Concerning performance. After reading your message I have realized that
it should be really fast to extract several thousand headings from a
buffer using regexp. However actually it is not so:
(benchmark-run 10 (and (org-refile-get-targets) nil))
| 9.868742533999999 | 40 | 2.999932755999996 |
So preparing the list of refile targets currently takes almost precisely
1 second. It is slow. Results are same for org-9.1.6 and
release_9.4.4-231-gf46925. I am surprised however that 9.1.6 and 9.3.1
are installed as system packages and have compiled files. I have not
compiled git version but it works with the same speed.
(length (org-refile-get-targets))
: 3220
Preferences:
(require 'org-refile)
(setq org-agenda-files '("~/notes/notes.org"))
(setq org-refile-use-cache nil)
(setq org-refile-use-outline-path t)
(setq org-outline-path-complete-in-steps nil)
(setq org-refile-targets '((org-agenda-files :maxlevel . 5)))
Some lines from profile:
- org-refile-get-targets 8414 74%
... - org-get-outline-path 7403 65%
... - org--get-outline-path-1 7286 64%
... - org-up-heading-safe 6328 56%
There is a room for improvement. Outline paths could be obtained in a
single pass without backward search. It should speed up building the
list of targets by 2 or 3 times.
Though it is unrelated to issues with default option and cache entries
when both ways to call org-refile are used: directly and through org-goto.
