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, 25 Mar 2018 13:35:07 -0400 Message-ID: References: <834lldp18f.fsf@gnu.org> <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de> <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> <83vadso9ad.fsf@gnu.org> <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> <1ea4248a-11ce-00a9-0644-df7b2e5a3a58@arkona-technologies.de> <838tajhsau.fsf@gnu.org> <837eq2j2i5.fsf@gnu.org> <834ll4gldp.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1521999207 32552 195.159.176.226 (25 Mar 2018 17:33:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2018 17:33:27 +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 Sun Mar 25 19:33:23 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 1f09WE-0008Of-V6 for ged-emacs-devel@m.gmane.org; Sun, 25 Mar 2018 19:33:23 +0200 Original-Received: from localhost ([::1]:52022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f09YI-0003Ma-4h for ged-emacs-devel@m.gmane.org; Sun, 25 Mar 2018 13:35:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f09Y1-0003Kp-Is for emacs-devel@gnu.org; Sun, 25 Mar 2018 13:35:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f09Xy-0007sg-CY for emacs-devel@gnu.org; Sun, 25 Mar 2018 13:35:13 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f09Xx-0007qZ-NT; Sun, 25 Mar 2018 13:35:10 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w2PHZ7H2000916; Sun, 25 Mar 2018 13:35:08 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 263CB66480; Sun, 25 Mar 2018 13:35:07 -0400 (EDT) In-Reply-To: <834ll4gldp.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Mar 2018 19:39:30 +0300") 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, RV6249=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6249> : inlines <6517> : streams <1782239> : uri <2614672> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:224013 Archived-At: > Agree with B1, but not with B2. Unless I'm overlooking something, > when the newline cache is disabled, we use memchr, which can search a > contiguous sequence of bytes in a loop, without translating > byte-to-character positions. It only needs this translation at the > beginning of search, after hitting the gap, and when the search is > completed. Hmm... indeed, when the newline cache is completely disabled the problem should not appear. >> The patch below tweaks my previous patch to take this into account. >> The result is now that my test cases stay fast (mostly unaffected by the >> number of markers) even for large buffers with a large number of markers. > This is a good change, I think. But it emphasizes even more the fact > that if we instead expose to Lisp display_count_lines, which is > basically a stripped-down version of find_newline with all the > unnecessary ballast removed, we will get an even better performance in > applications that need to count lines a lot. Yes, fixing A is definitely worthwhile. Stefan