GNU bug report logs - #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)

Previous Next

To reply to this bug, email your comments to 67326 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yuchen Pei <id <at> ypei.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 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 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.

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

Message #8 received at 67326 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuchen Pei <id <at> ypei.org>, gregory <at> heytings.org
Cc: 67326 <at> debbugs.gnu.org
Subject: Re: 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 <at> 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.

Message #13 received at 67326 <at> debbugs.gnu.org (full text, mbox):

From: Yuchen Pei <id <at> ypei.org>
To: bug#67326 <67326 <at> debbugs.gnu.org>
Subject: Re: 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: Sat, 25 Nov 2023 17:11:59 +1100

retitle 67326 29.1.90.1; time-stamp slowdown in large org file after org-refile-get-targets, caused by e7b5912b23 (Improvements to long lines handling)
thanks
> [... 66 lines elided]

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

Message #16 received at 67326 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Yuchen Pei <id <at> ypei.org>
Cc: 67326 <at> debbugs.gnu.org
Subject: Re: bug#67326: 29.1.90.1; time-stamp slowdown in large org file
 after org-refile-get-targets, caused by e7b5912b23 (Improvements to long
 lines handling)
Date: Fri, 12 Jan 2024 00:13:51 +0000

Hi Yuchen,

Thanks for your bug report, and sorry for the delay.

>
> 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.
>

I can't reproduce that bug alas, because I don't have that file.  I 
understand that it may contain private information.  Could you perhaps 
create a censored version of that file, and send it to me (privately, a 12 
MB attachments is too large for this list)?

>
> Like bug#57207,
>

This bug is likely not directly related to that one, as Ihor confirmed 
that it was fixed (and no other similar reports were filed since then).

>
> 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.
>

The reason for that is that development happened on feature branches, on 
which commits were not tagged as fixing specific bugs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.