line-number-at-pos performance and cache-long-scans

[Max Nikulin <manikulin@gmail.com>]

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.