Re: Clocking in is pretty slow in version 9.6 when the item has a large

> On Dec 7, 2022, at 10:36 AM, Ihor Radchenko wrote: > > Sorry, I meant (setq org-element--cache-self-verify nil). > In any case, the time is back to previous, which should be good enough > considering that no optimizations have been made to the clock table > calculation. I just realized my mi

Re: Clocking in is pretty slow in version 9.6 when the item has a large

Mark Barton writes: >> On Dec 7, 2022, at 3:53 AM, Ihor Radchenko wrote: >> >> What about setting org-element--cache-self-verify to nil? > > (setq org-element--cache-self-verify-frequency nil) > Update clocktable > Wrong type argument: number-or-marker-p, nil > > Try again but use zero instead

Re: Clocking in is pretty slow in version 9.6 when the item has a large

> On Dec 7, 2022, at 3:53 AM, Ihor Radchenko wrote: > > What about setting org-element--cache-self-verify to nil? (setq org-element--cache-self-verify-frequency nil) Update clocktable Wrong type argument: number-or-marker-p, nil Try again but use zero instead of nil... (setq org-element--cach

Re: Clocking in is pretty slow in version 9.6 when the item has a large

Mark Barton writes: > FYI here is how reducing that number helped with my clocktable updates in the > order I tested each value. > *** org-element--cache-self-verify-frequency 0.01 > update takes 1:18 (minutes : seconds) > *** org-element--cache-self-verify-frequency 0.005 > update takes 0:48 >

Re: Clocking in is pretty slow in version 9.6 when the item has a large

> On Dec 4, 2022, at 10:18 AM, Ihor Radchenko wrote: > > Ihor Radchenko mailto:yanta...@posteo.net>> writes: > >> Eli Qian mailto:eli.q.q...@gmail.com>> writes: >> >>> Any idea about speeding up clocking in? >> >> Try reducing `org-element--cache-self-verify-frequency' to a smaller >> number

Re: Clocking in is pretty slow in version 9.6 when the item has a large

Ihor Radchenko writes: > Eli Qian writes: > >> Any idea about speeding up clocking in? > > Try reducing `org-element--cache-self-verify-frequency' to a smaller > number. For some context, self-verify staff will only be enabled during pretest. It is an equivalent of ./configure --enable-checking

Re: [External] : Re: Clocking in is pretty slow in version 9.6 when the item has a large

Eli, I also had performance issues after the logbook was switched to true parsing instead of regular expressions.  In my case, I had logbook entries going back to 2012! After I cleared out the excess entries the performance jumped back up. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/

Re: Clocking in is pretty slow in version 9.6 when the item has a large

Eli Qian writes: > Any idea about speeding up clocking in? Try reducing `org-element--cache-self-verify-frequency' to a smaller number. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at

Re: Clocking in is pretty slow in version 9.6 when the item has a large

> On Dec 4, 2022, at 4:12 AM, Eli Qian wrote: > > After investigation by using profiler, I found the problem is caused by > `org-element-at-point` I'm also seeing this slowdown after compliling from Emacs master around the time of the 29.1 cutoff. I use the org version in Emacs master. I use

Clocking in is pretty slow in version 9.6 when the item has a large

I use the following method to get the time taken for `org-clocl-in`: (benchmark 1 '(org-clock-sum (org-clock-get-sum-start))) In my case, the item has 1400+ entries in its logbook, clocking in will cost 1-2s to finish(benchmark results: "Elapsed time: 1.689801s (0.527506s in 7 GCs)"). That's abno