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

Previous Next

Full log

Message #60 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 20:46:37 +0100

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

>> (with-temp-buffer
>>   (dotimes (_ 1000)
>>     (insert-file-contents "~/src/emacs/trunk/src/ChangeLog.11")
>>     (goto-char (point-max)))
>>   (benchmark-run 1
>>     (dotimes (i 100)
>>       (goto-char (* (/ (buffer-size) 100) i))
>>       (line-number-at-pos (point)))))
>> 
>> (Adjusted down to 100, because it takes too long.)  Let's see...
>> 
>> Yup, still 10x faster.
>
> This one traverses each 1/100th region of the file just once, no?

Did I write it wrong again?

    (dotimes (i 100)
      (goto-char (* (/ (buffer-size) 100) i))
      (line-number-at-pos (point)))))

No, that should be the entire buffer, spread out evenly?

>> OK, I've now bumped the benchmark-run to 10 (and decreased the buffer
>> size by a factor of 10)...  let's see...  The new version takes exactly
>> the same amount of time, of course...
>> 
>> And so does the old one.  Well, it's 10% faster in this?
>
> 10% or 10-fold?

10%.

>> And in buffers with lines with normal line lengths, it's 10x slower?
>
> In my benchmarks some years ago it was about twice slower, not 10
> times.

Perhaps memchr has gotten faster over the years?  Using larger memory
fetches and stuff?

-- 
(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.