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)

From: Eli Zaretskii <[email-masked]>
Date: Tue, 21 Nov 2023 16:31:22 +0200

> From: Yuchen Pei <[email-masked]>
> 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.