[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67326: 28.1.90.1; time-stamp slowdown in large org file after org-re
From: |
Eli Zaretskii |
Subject: |
bug#67326: 28.1.90.1; time-stamp slowdown in large org file after org-refile-get-targets, caused by e7b5912b23 (Improvements to long lines handling) |
Date: |
Tue, 21 Nov 2023 16:31:22 +0200 |
> From: Yuchen Pei <id@ypei.org>
> Date: Tue, 21 Nov 2023 23:23:16 +1100
>
>
> Previously reported in emacs-devel at
> https://lists.gnu.org/archive/html/emacs-devel/2023-06/msg00113.html
>
> Emacs built with
>
> ./configure --with-native-compilation --with-imagemagick --with-json
>
> Possibly related to bug#57207
>
> Set up: foo.org is a 12MB file, longest line 4753, about 21000
> headlines. It contains the timestamp thingie "Time-stamp: <....>" as one
> of the first few lines that already has a timestamp from before. Say the
> following file is called bar.el
>
> #+begin_src emacs-lisp
> (add-hook 'before-save-hook 'time-stamp)
> (require 'org-refile)
> (setq org-refile-use-cache t)
> (setq org-refile-use-outline-path t)
> (setq org-refile-targets '((nil :maxlevel . 5)))
> (setq org-goto-interface 'outline-path-completion)
> (setq large-file-warning-threshold 15000000)
> (find-file "foo.org")
> (org-refile-get-targets)
> #+end_src
>
> To reproduce, do
>
> ./src/emacs -Q -l bar.el foo.org
>
> followed by eval
>
> (time-stamp)
>
> It will take 10+ seconds to complete, and 10+ seconds if I undo
> afterwards.
>
> Like bug#57207,
>
> (setq long-line-threshold nil)
>
> is a workaround, and (time-stamp) completes instantly.
Adding Gregory to the discussion.
> I could not measure the precise time or have the whole process run in
> batch mode because:
>
> 1. It does not affect batch mode, presumably because of the change has
> to do with x display
> 2. (time-stamp) has funny pseudo-asynchronous behaviour: if I do
> (progn (time-stamp) (message "Done.")) the message evals immediately,
> long before time-stamp "completes" and unhangs emacs.
I think you misinterpret what happens: what takes a long time is not
time-stamp, but the redisplay after it. IOW, it isn't the evaluation
that takes time, it's the redisplay after it. But maybe I'm missing
something.
> BTW what is the commit that fixed bug#57207? I searched for commits in
> master and emacs-29 with message containing 57207 but could not find
> any.
It's 1c837c42c2, I think.