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>
Subject: bug#35675: closed (Re: bug#35675: 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 bug report

#35675: 27.0.50; Is line-number-at-pos unnecessarily slow?

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 35675 <at> debbugs.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: "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

[Message part 3 (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

Previous Next

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