--- Begin Message ---
|
Subject: |
27.0.50; Is line-number-at-pos unnecessarily slow? |
|
Date: |
Fri, 10 May 2019 15:55:09 -0500 |
|
User-agent: |
mu4e 1.2.0; emacs 27.0.50 |
Hi all -
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?
Thanks,
Alex
Footnotes:
[1]
https://fuco1.github.io/2018-08-12-WAR-STORY:-When-turning-to-the-profiler-turns-out-to-be-a-good-call.html
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#35675: 27.0.50; Is line-number-at-pos unnecessarily slow? |
|
Date: |
Tue, 14 May 2019 07:34:24 -0500 |
|
User-agent: |
mu4e 1.2.0; emacs 27.0.50 |
On Sat 11 May 2019 at 15:36, Basil L. Contovounesios <address@hidden> wrote:
> Alex Branham <address@hidden> writes:
>
>> line-number-at-pos basically regex searches forward for \n's and
>> counts them up.
>
> It only does this (via count-lines) if selective-display is t, which is
> deprecated and seldom used. Otherwise it uses the value returned by
> forward-line (defined in C), which calls find_newline, which AFAIK uses
> the buffer's newline cache to some extent (I'm not familiar with its
> implementation).
Thanks, I missed/misunderstood that part.
> Either way, as Eli says, there's often an algorithmic solution to
> slowness in uses of count-lines.
I'll take that advice and see if there's a more clever way to go about it.
Thanks again,
Alex
--- End Message ---