On 22/09/2022 14:03, Timothy wrote:
On 18/09/2022 10:09, Timothy wrote:
and now this might look like so:
┌────
│ executing Emacs-Lisp call on line 143…
│ Code block evaluation complete (took 0.2s).
└────
I do not mind to have such feature, but I am unsure concerning its price. I just
have tried
(benchmark-run 1 (line-number-at-pos))
(2.244481896 0 0.0)
What on earth did you run that on? I ran that on the last line of the Org manual
and here’s what I got:
┌────
│ (0.000219268 0 0.0)
└────
Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
It is an 8 years old laptop, minimal CPU frequency is 0.8GHz.
Org manual is ~5 times smaller than my file with notes and the former
contains not so much not ASCII characters.
For your test I get reasonable numbers
Emacs-26 0.038 or 0.084
Emacs-27 0.0066 or 0.0092
I am comfortable with performance. It seems, some optimization has been
done in Emacs since 26 release. I do not see dependence on Org version.
While I work with my notes file, performance degrades after some
operations. E.g. searches become significantly slower after caching
refile targets. Previous discussion of the issue:
Ihor Radchenko. Re: profiling latency in large org-mode buffers (under
both main & org-fold feature) Sun, 27 Feb 2022 14:43:29 +0800.
https://list.orgmode.org/87y21wkdwu.fsf@localhost
My experience is that e.g. emacsclient with particular line causes
several seconds hang.
Despite improvements since Emacs-26 in line counting, still I believe
that the `line-number-at-pos' function may still be excessively
expensive in real live when unconditionally used just for a bit nicer
logging.
