[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] org-goto slows down org-set-property

From: Maxim Nikulin
Subject: Re: [BUG] org-goto slows down org-set-property
Date: Sun, 11 Jul 2021 16:25:30 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 10/07/2021 22:47, Maxim Nikulin wrote:
It is rather annoying that C-c C-x p `org-set-property' may be quite slow if a file is large enough. (I do not consider it huge however.) There is noticeable delay before the prompt for property name appears in minibuffer. Accidentally I have noticed that sometimes it is fast.

Problem appears after first jump using C-u C-c C-j `org-goto'. Actually a jump is not required, it is enough to get jump (refile) targets.

It is strange. Merely 3500 markers created by org-refile-cache in 2.2Mb file ruin performance of regexps in that buffer. I would expect either no influence of markers at all since search is a read-only operation or some negligible penalty proportional to fraction of markers in relation to total amount of characters.

Look at the numbers for nm-test that is just some regexp searches from `org-buffer-property-keys'. Performance is restored after clearing of the cache.

#+begin_src elisp
  (defun nm-tst ()
     (goto-char (point-min))
     (while (re-search-forward org-property-start-re nil t)


  (let ((org-refile-targets '((nil :maxlevel . 6)))
        (org-refile-use-outline-path 'file)
        (org-refile-use-cache t)
        (iters 10))
     (list (org-version))
     (mapcar (lambda (f)
               (append (list f) (benchmark-run iters (funcall f))))
             (list #'nm-tst ; #'org-buffer-property-keys
                   #'nm-tst ; #'org-buffer-property-keys

| 9.4.6                  |             |   |                    |
| nm-tst                 | 0.044981942 | 0 |                0.0 |
| org-refile-get-targets | 1.748572638 | 8 | 0.3876601379999993 |
| nm-tst                 | 0.393022201 | 0 |                0.0 |
| org-refile-cache-clear | 0.001787078 | 0 |                0.0 |
| nm-tst                 | 0.035731803 | 0 |                0.0 |

It seems, it is better to drop org-refile-cache completely. It has some design problems making it rather fragile. At the same time a patch can be applied that improves performance of `org-refile-get-targets' by a factor of at least 2 for (org-refile-use-outline-path 'file).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]