From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Mon, 19 Mar 2018 08:29:40 -0400 Message-ID: References: > <834lldp18f.fsf@gnu.org>> <83tvtco8xl.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521462479 31307 195.159.176.226 (19 Mar 2018 12:27:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2018 12:27:59 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 13:27:55 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1exttJ-00081n-C9 for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 13:27:53 +0100 Original-Received: from localhost ([::1]:41813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1extvM-0006NG-Ab for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 08:30:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1extvB-0006Lk-9Q for emacs-devel@gnu.org; Mon, 19 Mar 2018 08:29:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1extv6-0005te-DJ for emacs-devel@gnu.org; Mon, 19 Mar 2018 08:29:49 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1extv6-0005s5-7L; Mon, 19 Mar 2018 08:29:44 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w2JCTe0H003805; Mon, 19 Mar 2018 08:29:41 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5CDB9608AD; Mon, 19 Mar 2018 08:29:40 -0400 (EDT) In-Reply-To: <83tvtco8xl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 19 Mar 2018 08:50:46 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6244=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6244> : inlines <6499> : streams <1781647> : uri <2611030> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223812 Archived-At: >> It should be pretty easy to provide such a thing by relying on a cache >> of the last call. > This is already coded, see display_count_lines. I don't see any cache in display_count_lines but yes, the code that uses display_count_lines does do such caching and we could/should expose it to Lisp. In nlinum.el I also have something similar (called nlinum--line-number-at-pos). > But I don't believe it could be orders of magnitude faster than > count-lines, even though it doesn't need to convert character position > to byte position. Scanning from the last used position can be *very* different from scanning from point-min. So yes, it can be orders of magnitude faster (I wrote nlinum--line-number-at-pos for that reason: I sadly didn't write down the test case I used back then, but the difference was very significant). > I'm guessing something entirely different and unrelated to > line-counting per se is at work here. Agreed. >> Tho Sebastian's experience seems to indicate that the >> current code doesn't only suffer from the time to count LF but also from >> the time to process the markers. > Not sure what marker processing did you have in mind. Can you > elaborate? The for (tail = BUF_MARKERS (b); tail; tail = tail->next) loop in buf_charpos_to_bytepos and buf_bytepos_to_charpos. > But find_newline doesn't look for markers, and it converts character > to byte position just 2 times. Or am I missing something? The idea is that the above loop (even if called only twice) might be sufficient to make line-number-at-pos take 0.2s. I don't know that it's the culprit, I'm just mentioning that possibility, since noverlays removes all the overlay-induced markers which would significantly reduce the number of markers over which the above loops. Note that those loops stop as soon as we're within 50 chars of the goal, and they also stop as soon as there's no non-ascii char between the "best bounds so far". So for them to cause the slow down seen here, we'd need not only a very large number of markers but also additional conditions that might not be very likely. But it's still a possibility. Stefan