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: Sun, 18 Mar 2018 21:33:05 -0400 Message-ID: References: > <834lldp18f.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521423088 30924 195.159.176.226 (19 Mar 2018 01:31:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2018 01:31:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 02:31:24 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 1exje0-0007wd-GY for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 02:31:24 +0100 Original-Received: from localhost ([::1]:39794 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exjg3-00066y-Fq for ged-emacs-devel@m.gmane.org; Sun, 18 Mar 2018 21:33:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exjfx-00066a-My for emacs-devel@gnu.org; Sun, 18 Mar 2018 21:33:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1exjfu-0007h1-KM for emacs-devel@gnu.org; Sun, 18 Mar 2018 21:33:25 -0400 Original-Received: from [195.159.176.226] (port=47724 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1exjfu-0007gL-D2 for emacs-devel@gnu.org; Sun, 18 Mar 2018 21:33:22 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1exjdk-0007dv-Es for emacs-devel@gnu.org; Mon, 19 Mar 2018 02:31:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 21 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:QfMRUcxzKjmExQbekG6sWWa93n8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:223799 Archived-At: >> If lsp-mode/lsp-ui needs a fast line counter, one can easily be >> provided by exposing find_newline to Lisp. IME, it's lightning-fast, >> and should run circles around count-lines (used by line-number-at-pos). > Having a fast line counter in Elisp would be terrific. It should be pretty easy to provide such a thing by relying on a cache of the last call. 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. I seem to remember someone else experiencing a similar problem and suggesting that the problem lies in the charpos_to_bytepos (and/or bytepos_to_charpos) conversion function, which iterates through all the markers to try and find a "nearby" marker (because markers keep track of both their bytepos and their charpos). Looking for a nearby marker to avoid scanning the whole buffer is a good idea in many cases, but not if scanning the list of markers takes more time than scanning the whole buffer. Stefan