GNU bug report logs - #22763
25.1.50; Feature Request -- A faster method to obtain line number at position.

Previous Next

Full log

Message #36 received at 22763 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22763 <at> debbugs.gnu.org, esq <at> lawlist.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#22763: 25.1.50; Feature Request -- A faster method to
 obtain line number at position.
Date: Sun, 07 Feb 2021 19:14:08 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> There's no caching.  I guess find_newline is just slow compared to
>> display_count_lines?
>
> find_newline does the same as display_count_lines: it calls memchr.
> But it also maintains a newline cache.  If you disable that cache (by
> turning of cache-long-scans), you might see a different speedup.

Shouldn't the cache speed things up?

Hm...  perhaps I'm not getting a newline cache in my tests because I'm
using a temp buffer or something?

> Also, calling forward-line would loop in Lisp, not in C.

No, it cleverly loops in C by calling `forward-line' this way to count
lines:

(- (buffer-size) (forward-line (buffer-size)))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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