From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: line-number-at-pos performance and cache-long-scans
Date: Fri, 23 Sep 2022 23:21:54 +0700 [thread overview]
Message-ID: <tgkmf4$4ag$1@ciao.gmane.io> (raw)
In-Reply-To: <87v8pe96dm.fsf@localhost>
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.
next prev parent reply other threads:[~2022-09-23 16:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 3:09 [PATCH] Babel evaluation: location and timing information Timothy
2022-09-19 12:28 ` Fraga, Eric
2022-09-19 14:52 ` Max Nikulin
2022-09-22 7:03 ` Timothy
2022-09-22 12:15 ` Max Nikulin
2022-09-23 2:22 ` Ihor Radchenko
2022-09-23 16:21 ` Max Nikulin [this message]
2022-09-20 8:29 ` Ihor Radchenko
2022-09-22 7:05 ` Timothy
2022-09-23 2:27 ` Ihor Radchenko
2022-09-23 16:46 ` [PATCH] Babel evaluation: location and timing information (v2) Timothy
2022-09-24 3:11 ` Ihor Radchenko
2022-09-24 9:12 ` Timothy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='tgkmf4$4ag$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).