[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
line-number-at-pos performance and cache-long-scans
From: |
Max Nikulin |
Subject: |
line-number-at-pos performance and cache-long-scans |
Date: |
Fri, 23 Sep 2022 23:21:54 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 |
On 23/09/2022 09:22, Ihor Radchenko wrote:
Max Nikulin writes:
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.
May I ask if other Org operations are also slow in that problematic file
with many markers? If so, I do not think that we need to worry about
performance of `line-number-at-pos'. Rather we just wait for Emacs to
fix problems with markers. See the discussion in
https://yhetil.org/emacs-devel/jwvsfntduas.fsf-monnier+emacs@gnu.org
Thank you for the link. It would be great if that branch were merged. My
primary complain concerning line numbers is that there is no way to
disable the feature.
Ihor, the following is not answer to your question. I am impressed by
such observation, however it is not latest Emacs version and built-in
Org that uses overlays, not text properties.
It seems, in the case of `line-number-at-pos' another "optimization"
causes performance degradation by orders of magnitude, not markers as
for conversion between byte offset and position in buffers. I have found
a discussion of a change in Emacs-28 (So it is not clear for me why I
see performance difference between Emacs-26 and 27, maybe more optimal
code generated by newer gcc)
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22763
25.1.50; Feature Request -- A faster method to obtain line number at
position.
I noticed `cache-long-scans' and tried to disable it.
If my document (4Mb, 100k lines) is open as .txt file in Emacs-26
getting line number at the end takes 0.03…0.04 s. If I enable org-mode
the same operation requires 6s, but after
(setq cache-long-scans nil)
0.006 s is enough to get the same line number. Enabling the cache again
causes performance degradation by 3 orders of magnitude. Cache works to
some extent because first call takes 12 s while following ones "only" 6 s.
I have not tried if disabling newline cache causes problems with other
operation.
Re: [PATCH] Babel evaluation: location and timing information, Ihor Radchenko, 2022/09/20
Re: [PATCH] Babel evaluation: location and timing information (v2), Timothy, 2022/09/23