GNU bug report logs - #35675
27.0.50; Is line-number-at-pos unnecessarily slow?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alex Branham <alex.branham <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#35675: closed (27.0.50; Is line-number-at-pos unnecessarily
 slow?)
Date: Tue, 14 May 2019 12:35:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 14 May 2019 07:34:24 -0500
with message-id <87a7fp8ban.fsf <at> gmail.com>
and subject line Re: bug#35675: 27.0.50; Is line-number-at-pos unnecessarily slow?
has caused the debbugs.gnu.org bug report #35675,
regarding 27.0.50; Is line-number-at-pos unnecessarily slow?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
35675: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35675
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Alex Branham <alex.branham <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Is line-number-at-pos unnecessarily slow?
Date: Fri, 10 May 2019 15:55:09 -0500

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

[Message part 3 (message/rfc822, inline)]

From: Alex Branham <alex.branham <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35675-done <at> debbugs.gnu.org
Subject: Re: bug#35675: 27.0.50; Is line-number-at-pos unnecessarily slow?
Date: Tue, 14 May 2019 07:34:24 -0500

On Sat 11 May 2019 at 15:36, Basil L. Contovounesios <contovob <at> tcd.ie> wrote:

> Alex Branham <alex.branham <at> gmail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.