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

Previous Next

Package: emacs;

Reported by: Alex Branham <alex.branham <at> gmail.com>

Date: Fri, 10 May 2019 20:56:01 UTC

Severity: normal

Found in version 27.0.50

Done: Alex Branham <alex.branham <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #16 received at 35675-done <at> debbugs.gnu.org (full text, mbox):

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




This bug report was last modified 6 years and 61 days ago.

Previous Next


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