Morgan Smith <morgan.j.sm...@outlook.com> writes:
> I have a very big file with lots of clock entries and refreshing my clocktable
> has become slow. Using '(benchmark-elapse (org-ctrl-c-ctrl-c))' I saw that it
> took 5.660532903 seconds to refresh it! After this rewrite it only takes
> 3.384914703 seconds. Not great, but better.
Thanks, but the approach you used is questionable.
You are forcing Org to parse the whole buffer as opposed to the existing
approach with parsing only the necessary parts.
While I do see how your implementation might be faster for certain Org
files (many clock entries, little other elements), but I do not see how
it can be faster in general case.
May you instead share the benchmark data for the original Org's code on
your file?
1. M-x profiler-start <RET> cpu <RET>
2. Generate the clock table
3. M-x profiler-report <RET>
4. M-x profiler-report-write-profile
5. Share the saved profile file
P.S.
I did a benchmark on another large buffer and with the existing
implementation I am getting (first column is time in ms):
15989 58% - org-clock-sum
15837 58% -
org-element-at-point
15517 56% +
org-element--parse-to
With your code
27347 87% - org-clock-sum
27347 87% - let*
27347 87% - unwind-protect
27347 87% - progn
27347 87% - let*
27310 87% - org-element-map
27230 87% +
org-element-parse-buffer
and the code is not yet even done, stopping processing due to error.
Further, you dropped the
((match-end 4)
;; A naked time.
branch of the code, which accounts for CLOCK: => HH:MM lines that are not clock
elements.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
