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: Tue, 20 Mar 2018 02:23:02 +0100 Message-ID: <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> 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> 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 1521508903 18481 195.159.176.226 (20 Mar 2018 01:21:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Mar 2018 01:21:43 +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 Tue Mar 20 02:21:39 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 1ey5y5-0004i9-DO for ged-emacs-devel@m.gmane.org; Tue, 20 Mar 2018 02:21:37 +0100 Original-Received: from localhost ([::1]:44830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ey608-0004o6-MJ for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 21:23:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ey5za-0004mo-Je for emacs-devel@gnu.org; Mon, 19 Mar 2018 21:23:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ey5zV-0002Sf-J9 for emacs-devel@gnu.org; Mon, 19 Mar 2018 21:23:10 -0400 Original-Received: from smtp-out003.kontent.com ([81.88.40.217]:57015) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ey5zV-0002QU-8R for emacs-devel@gnu.org; Mon, 19 Mar 2018 21:23:05 -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-out003.kontent.com) by smtp-out003.kontent.com (Postfix) with ESMTPSA id 03FCB4000CCA for ; Tue, 20 Mar 2018 02:23:02 +0100 (CET) In-Reply-To: <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 81.88.40.217 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:223841 Archived-At: after disabling cquery for testing purposes (which leaves me with 45=20 overlays generated by flycheck for my troublesome C++ file), I'm now=20 generating a large number of overlays using the following function: (defun test-highlight () (save-excursion (with-silent-modifications (let ((stepsize 10)) (widen) (goto-char 1) (cl-loop for n from (point-min) upto (- (point-max)=20 stepsize) by stepsize do (let ((ov (make-overlay n (+ (1- stepsize) n)))) (overlay-put ov 'cquery-sem-highlight t))))))) Evaluating the following function without additional overlays (beyond=20 the flycheck ones, that is) yields the following results: (defun benchmark-often () (cl-loop for n from 1 upto 20 do (message (format "iteration %d: %f" n (nth 0 (benchmark-run=20 (line-number-at-pos (point)))))))) 1st run: iteration 1: 0.001213 iteration 2: 0.001170 iteration 3: 0.001170 iteration 4: 0.001238 iteration 5: 0.001163 iteration 6: 0.001153 iteration 7: 0.000421 iteration 8: 0.000426 iteration 9: 0.000322 iteration 10: 0.000301 iteration 11: 0.000291 iteration 12: 0.000292 iteration 13: 0.000291 iteration 14: 0.000291 iteration 15: 0.000295 iteration 16: 0.000289 iteration 17: 0.000289 iteration 18: 0.000288 iteration 19: 0.000288 iteration 20: 0.000287 2nd run: iteration 1: 0.001044 iteration 2: 0.000942 iteration 3: 0.000935 iteration 4: 0.000935 iteration 5: 0.000935 iteration 6: 0.000932 iteration 7: 0.000954 iteration 8: 0.000940 iteration 9: 0.000933 iteration 10: 0.000625 iteration 11: 0.000545 iteration 12: 0.000428 iteration 13: 0.000362 iteration 14: 0.000346 iteration 15: 0.000325 iteration 16: 0.000309 iteration 17: 0.000309 iteration 18: 0.000316 iteration 19: 0.000310 iteration 20: 0.000308 after evaluating (test-highlight) the figures are as follows: 1st run: iteration 1: 0.026012 iteration 2: 0.020334 iteration 3: 0.020250 iteration 4: 0.020349 iteration 5: 0.020501 iteration 6: 0.020635 iteration 7: 0.020302 iteration 8: 0.020426 iteration 9: 0.020440 iteration 10: 0.020441 iteration 11: 0.020515 iteration 12: 0.020525 iteration 13: 0.020383 iteration 14: 0.020510 iteration 15: 0.019829 iteration 16: 0.019899 iteration 17: 0.019950 iteration 18: 0.019828 iteration 19: 0.019901 iteration 20: 0.019819 2nd run: iteration 1: 0.026526 iteration 2: 0.020051 iteration 3: 0.020100 iteration 4: 0.020080 iteration 5: 0.020080 iteration 6: 0.020249 iteration 7: 0.020087 iteration 8: 0.020005 iteration 9: 0.019980 iteration 10: 0.019985 iteration 11: 0.020077 iteration 12: 0.019979 iteration 13: 0.020060 iteration 14: 0.020092 iteration 15: 0.019954 iteration 16: 0.019766 iteration 17: 0.019432 iteration 18: 0.019491 iteration 19: 0.019458 iteration 20: 0.019482 I'm not allowed to share my employer's source code as a test case, so I=20 tried the same procedure with the similarly large DeclBase.h from the=20 public LLVM repository. To my surprise, DeclBase.h didn't suffer from=20 any performance issues at all. Switching to fundamental-mode while=20 visiting my file didn't change anything, so I assume that c-mode isn't=20 to blame either. There have been claims of overlay-related performance issues with cquery=20 and some large(-ish) open-source C or C++ files, so I'll try to locate=20 these files and hope that at least one of them exhibits this issue as wel= l. On 03/19/2018 04:07 PM, Sebastian Sturm wrote: > for the file I was complaining about, the number returned is 3080=20 > (doesn't exceed the number of chars though, (point-max) =3D 67641). Wil= l=20 > try to obtain usable timing data later today when I get home from work.= =20 > Thanks! >=20 > On 03/19/2018 03:56 PM, Stefan Monnier wrote: >>> well no, it's about 2.5ms per call to line-number-at-pos, which is=20 >>> called at >>> least 6 times per character insertion (with my Emacs config, at >>> least). Which already makes for 15ms per character insertion, excludi= ng >>> anything else done by cc-mode or lsp-mode. >> >> Since you say that the noverlay branch helps, could you check the numb= er >> of overlays involved?=C2=A0 E.g. >> >> =C2=A0=C2=A0=C2=A0=C2=A0 M-: (length (overlays-in (point-min) (point-m= ax))) RET >> >> If there are more overlays than chars in this buffer, maybe there's >> a problem in some Elisp that creates too many overlays? >> >> If there aren't that many overlays, then I wonder why the noverlays >> branch would make such a significant difference. >> >> Also, if you can reliably reproduce the "slow editing", would it be >> possible to make a recipe for it that we can try and reproduce on >> our side? >> >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Stefan >> >> >=20