From: Eli Zaretskii <eliz@gnu.org>
To: Alex Branham <alex.branham@gmail.com>
Cc: 35675@debbugs.gnu.org
Subject: bug#35675: 27.0.50; Is line-number-at-pos unnecessarily slow?
Date: Sat, 11 May 2019 09:03:14 +0300 [thread overview]
Message-ID: <83tve1edel.fsf@gnu.org> (raw)
In-Reply-To: <87zhnuuj0y.fsf@gmail.com> (message from Alex Branham on Fri, 10 May 2019 15:55:09 -0500)
> From: Alex Branham <alex.branham@gmail.com>
> Date: Fri, 10 May 2019 15:55:09 -0500
>
> I ran into a bottleneck at line-number-at-pos in ESS's indentation
> engine. line-number-at-pos basically regex searches forward for \n's and
> counts them up. This can be slow in a large buffer. It looks like
> someone else has ran into this issue as well.[1]
>
> With the advent of display-line-numbers-mode, I imagine there's a C
> implementation of line-number-at-pos. I imagine the C implementation is
> faster. Does it make sense for line-number-at-pos to just use the C
> implementation?
The C implementation was always there: it's what's behind the Lnn
display in the mode line. display-line-numbers-mode just reuses that
fir its purposes, but basically invents nothing new in that
department.
The usual wisdom regarding line-number-at-pos is to use count-lines
instead, counting the number of lines since some previous line whose
number is recorded. (By contrast, line-number-at-pos always starts
from BOB.) For example, you could always have the line number of the
first line in the window in some variable, and recompute it only when
that line goes off the window. If this strategy somehow doesn't work
in your case, please describe that use case in more detail, as IME it
is very rare (read: non-existent).
Using the C implementation we have from Lisp might not be as
straight-forward as you'd think, because it caches various values in
the window object, and relies on them being up-to-date. Code that
runs during redisplay can rely on some assumption that Lisp cannot.
One obvious difficulty is that you may need your Lisp program to count
line in a buffer that isn't displayed in any window.
Therefore, my suggestion is to get back to the drawing board and
analyze your use case. I'd be very surprised if a solution simpler
than just counting all the lines from BOB will not present itself.
next prev parent reply other threads:[~2019-05-11 6:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 20:55 bug#35675: 27.0.50; Is line-number-at-pos unnecessarily slow? Alex Branham
2019-05-11 6:03 ` Eli Zaretskii [this message]
2019-05-11 20:36 ` Basil L. Contovounesios
2019-05-14 12:34 ` Alex Branham
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83tve1edel.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=35675@debbugs.gnu.org \
--cc=alex.branham@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.