From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Sebastian Sturm Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Fri, 23 Mar 2018 00:11:16 +0100 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1521760170 32676 195.159.176.226 (22 Mar 2018 23:09:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2018 23:09:30 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 00:09:26 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 1ez9Km-0008Nr-Nu for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 00:09:24 +0100 Original-Received: from localhost ([::1]:35275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez9Mp-000508-Gn for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2018 19:11:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ez9Mf-0004zb-Pp for emacs-devel@gnu.org; Thu, 22 Mar 2018 19:11:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ez9Mc-0005la-Ku for emacs-devel@gnu.org; Thu, 22 Mar 2018 19:11:21 -0400 Original-Received: from smtp-out002.kontent.com ([81.88.40.216]:48664) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ez9Mc-0005lB-Ad for emacs-devel@gnu.org; Thu, 22 Mar 2018 19:11:18 -0400 Original-Received: from [192.168.0.102] (unknown [82.195.74.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: arkona-technologies_de_22@smtp-out002.kontent.com) by smtp-out002.kontent.com (Postfix) with ESMTPSA id DE584C004327E for ; Fri, 23 Mar 2018 00:11:16 +0100 (CET) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 81.88.40.216 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:223929 Archived-At: On 03/22/2018 09:52 PM, Stefan Monnier wrote: >> (defun benchmark-often () >> (cl-loop for n from 1 upto 20 do >> (message (format "iteration %d: %f" n (nth 0 (benchmark-ru= n >> (line-number-at-pos (point)))))))) > ^^^^^^^ > Where is this "point" in your tests (I expect the timing to vary > significantly depending on this). yes, these tests were all performed close to the very bottom of the file=20 as I knew the issue to get worse towards the buffer end > My crystal ball tells me that DeclBase.h is pure ASCII so byte<->char > conversion is trivial, whereas your file likely contains umlauts and > other disreputable characters. >=20 > Here's a similar test case to yours but which builds up its own > artificial buffer with a few non-ascii chars to spice things up: thank you! I'm very glad you could come up with a reproducible test=20 case, and it's true that my file contains two instances of the greek=20 letter "=CE=BC" that seem to cause this performance issue (though I was=20 surprised to see that this few characters could have such a poisonous=20 effect). Likewise, when replacing the topmost part in your benchmark=20 function with the following: (A) (dotimes (i 1000) (insert "pure ascii pure ascii pure ascii\n")) (B) (dotimes (i 500) (insert "pure ascii pure ascii pure ascii\n")) (insert "=CE=BC") (dotimes (i 500) (insert "pure ascii pure ascii pure ascii\n")) respectively, I obtain the following timing results: (A) ols=3D3300 pos=3D0/4 time=3D0.0014 (+ (0 0.0)) ols=3D3300 pos=3D1/4 time=3D0.0155 (+ (0 0.0)) ols=3D3300 pos=3D2/4 time=3D0.0281 (+ (0 0.0)) ols=3D3300 pos=3D3/4 time=3D0.0447 (+ (0 0.0)) ols=3D206 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D206 pos=3D1/4 time=3D0.0130 (+ (0 0.0)) ols=3D206 pos=3D2/4 time=3D0.0283 (+ (0 0.0)) ols=3D206 pos=3D3/4 time=3D0.0447 (+ (0 0.0)) ols=3D12 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D12 pos=3D1/4 time=3D0.0129 (+ (0 0.0)) ols=3D12 pos=3D2/4 time=3D0.0281 (+ (0 0.0)) ols=3D12 pos=3D3/4 time=3D0.0447 (+ (0 0.0)) ols=3D0 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D0 pos=3D1/4 time=3D0.0134 (+ (0 0.0)) ols=3D0 pos=3D2/4 time=3D0.0297 (+ (0 0.0)) ols=3D0 pos=3D3/4 time=3D0.0463 (+ (0 0.0)) (B) ols=3D3300 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D3300 pos=3D1/4 time=3D0.0301 (+ (0 0.0)) ols=3D3300 pos=3D2/4 time=3D0.0482 (+ (0 0.0)) ols=3D3300 pos=3D3/4 time=3D8.0213 (+ (0 0.0)) ols=3D206 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D206 pos=3D1/4 time=3D0.0141 (+ (0 0.0)) ols=3D206 pos=3D2/4 time=3D0.0325 (+ (0 0.0)) ols=3D206 pos=3D3/4 time=3D0.1786 (+ (0 0.0)) ols=3D12 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D12 pos=3D1/4 time=3D0.0136 (+ (0 0.0)) ols=3D12 pos=3D2/4 time=3D0.0323 (+ (0 0.0)) ols=3D12 pos=3D3/4 time=3D0.0794 (+ (0 0.0)) ols=3D0 pos=3D0/4 time=3D0.0009 (+ (0 0.0)) ols=3D0 pos=3D1/4 time=3D0.0139 (+ (0 0.0)) ols=3D0 pos=3D2/4 time=3D0.0326 (+ (0 0.0)) ols=3D0 pos=3D3/4 time=3D0.0632 (+ (0 0.0)) by comparison, these are my results using the noverlay branch: (A) ols=3D3300 pos=3D0/4 time=3D0.0012 (+ (0 0.0)) ols=3D3300 pos=3D1/4 time=3D0.0132 (+ (0 0.0)) ols=3D3300 pos=3D2/4 time=3D0.0291 (+ (0 0.0)) ols=3D3300 pos=3D3/4 time=3D0.0448 (+ (0 0.0)) ols=3D206 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D206 pos=3D1/4 time=3D0.0132 (+ (0 0.0)) ols=3D206 pos=3D2/4 time=3D0.0290 (+ (0 0.0)) ols=3D206 pos=3D3/4 time=3D0.0454 (+ (0 0.0)) ols=3D12 pos=3D0/4 time=3D0.0008 (+ (0 0.0)) ols=3D12 pos=3D1/4 time=3D0.0131 (+ (0 0.0)) ols=3D12 pos=3D2/4 time=3D0.0287 (+ (0 0.0)) ols=3D12 pos=3D3/4 time=3D0.0452 (+ (0 0.0)) ols=3D0 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D0 pos=3D1/4 time=3D0.0131 (+ (0 0.0)) ols=3D0 pos=3D2/4 time=3D0.0289 (+ (0 0.0)) ols=3D0 pos=3D3/4 time=3D0.0457 (+ (0 0.0)) (B) ols=3D3300 pos=3D0/4 time=3D0.0015 (+ (0 0.0)) ols=3D3300 pos=3D1/4 time=3D0.0177 (+ (0 0.0)) ols=3D3300 pos=3D2/4 time=3D0.0345 (+ (0 0.0)) ols=3D3300 pos=3D3/4 time=3D0.0544 (+ (0 0.0)) ols=3D206 pos=3D0/4 time=3D0.0008 (+ (0 0.0)) ols=3D206 pos=3D1/4 time=3D0.0136 (+ (0 0.0)) ols=3D206 pos=3D2/4 time=3D0.0317 (+ (0 0.0)) ols=3D206 pos=3D3/4 time=3D0.0537 (+ (0 0.0)) ols=3D12 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D12 pos=3D1/4 time=3D0.0135 (+ (0 0.0)) ols=3D12 pos=3D2/4 time=3D0.0319 (+ (0 0.0)) ols=3D12 pos=3D3/4 time=3D0.0537 (+ (0 0.0)) ols=3D0 pos=3D0/4 time=3D0.0007 (+ (0 0.0)) ols=3D0 pos=3D1/4 time=3D0.0146 (+ (0 0.0)) ols=3D0 pos=3D2/4 time=3D0.0318 (+ (0 0.0)) ols=3D0 pos=3D3/4 time=3D0.0554 (+ (0 0.0)) since noverlay performs so well, I guess the technical issue here is=20 already solved and I'll just have to wait for it to make it into the=20 master branch. Until then I'll continue using feature/noverlay, but if a=20 more recent merge with master was made available, I'd be interested in=20 testing that. thanks again for all the helpful responses in this thread, Sebastian