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)

[Yuchen Pei <id@ypei.org>]

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.

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.

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.

Best,
Yuchen

--
Dr Yuchen Pei | https://ypei.org | Timezone: UTC+11
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
https://ypei.org/assets/ypei-pubkey.txt