On 19/03/2021 22:07, Ihor Radchenko wrote:
Maxim Nikulin writes:
I could not guess how to benchmark font-lock. I have tried to open file
(to get everything loaded), kill the buffer,
I usually just use profiler-start/open buffer/profiler-report. However,
there is also https://github.com/Lindydancer/font-lock-profiler for more
fine-grained benchmark. Also, you may instrument org-activate-links with
elp.el (built-in).
I suspect I may not notice performance penalty due to some specific
usage pattern (e.g. I rarely use links in heading titles) or due to
absence of some customization. I have converted bracketed links to plain
ones, so I have more than 4000 links in the test file. I expect that
regexp affects loading of a file. As earlier, org-activate-links entry
in profiler-report have less than 1%. I have tried elp. My measurements
are not accurate due to I did not fix CPU regime to performance. I have
seen times varied quite widely (several times) but often the numbers are
the same with and without your patch. I am puzzled a bit by number of calls.
(progn
(require 'elp)
(setq elp-function-list (list #'org-activate-links))
(elp-instrument-list nil)
(dolist (i (number-sequence 1 10))
(message "iter %d" i)
(find-file "plain.org")
(sit-for 3)
(kill-buffer "plain.org")
(sit-for 1))
(elp-results))
Example for #+STARTUP: overview:
org-activate-links 560 0.028971085 5.173...e-05
For content number of calls is 410, without special settings (all) 120,
let me remind that it is for 10 find-file invocations. Another example
org-activate-links 410 0.1384633219 0.0003377154
I see such variations in both cases with and without the patch, but
these numbers are negligible in my opinion.
I decided to stop experiments since I could not reproduce decrease in
performance. Thank you for the font-lock-profiler link however.
So I have no reason to be against more complicated regexp.
Are changes in white spaces below actually modified lines in your patch
intended?
They are generated by aggressive-indent. Since org files mix indentation
styles I keep getting those whitespace changes in my patches. Forgot to
remove this time. Should I?
In my opinion, combining changes related to white spaces and meaningful
modifications makes commits less clear, especially when reading email.
However the following recommendation has certainly more weight:
https://orgmode.org/list/87zh2hosex....@bzg.fr/ From: Bastien
Also, the convention in Emacs is to avoid whitespaces-only commits,
you need to fix whitespaces within other non-whitespaces changes in
a commit.
