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: Mon, 19 Mar 2018 10:53:52 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1521453178 2941 195.159.176.226 (19 Mar 2018 09:52:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2018 09:52:58 +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 Mon Mar 19 10:52:54 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 1exrTJ-0000f2-4g for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 10:52:53 +0100 Original-Received: from localhost ([::1]:41034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exrVM-0007oF-Dr for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2018 05:55:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exrUL-0007m9-T0 for emacs-devel@gnu.org; Mon, 19 Mar 2018 05:53:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1exrUI-0003l1-RE for emacs-devel@gnu.org; Mon, 19 Mar 2018 05:53:57 -0400 Original-Received: from smtp-out003.kontent.com ([81.88.40.217]:55769) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1exrUI-0003kb-GD for emacs-devel@gnu.org; Mon, 19 Mar 2018 05:53:54 -0400 Original-Received: from [172.16.222.49] (unknown [213.157.6.138]) (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 C79A04000B61 for ; Mon, 19 Mar 2018 10:53:52 +0100 (CET) In-Reply-To: <83vadso9ad.fsf@gnu.org> 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:223808 Archived-At: On 03/19/2018 07:43 AM, Eli Zaretskii wrote: >> From: Sebastian Sturm >> Date: Mon, 19 Mar 2018 00:20:13 +0100 >> >> for the record, I just switched back to emacs master (no noverlay) and >> the time reported by (benchmark-run 1000 (line-number-at-pos (point)) >> increased by a factor of ~40, to 75-80s. At this level, editing is >> unbearably slow. With the semantic highlighter disabled, the same >> measurement yields ~2.5s (still painfully slow, but borderline usable), >> so about the same time reported by the noverlay branch. > > You will have to explain why overlays and the semantic highlighter > affect line-counting. How about presenting a profile produced by > "M-x profiler-report"? please find below a profiler report taken this morning (on my PC at work, which doesn't suffer from the performance issue as much as my 2014 MacBook Pro, but even here the issue is clearly noticeable) > > And the timings you measure are 2.5 _milliseconds_ (the benchmark runs > 1000 times), right? If so, I cannot understand why you say that's > borderline usable, because IME such short times are imperceptible by > humans. I guess some other factor is at work here, so I'd suggest to > describe more details about your use case. well no, it's about 2.5ms per call to line-number-at-pos, which is called at least 6 times per character insertion (with my Emacs config, at least). Which already makes for 15ms per character insertion, excluding anything else done by cc-mode or lsp-mode. >> Since the time taken by line-number-at-pos seems to fluctuate wildly for >> (to me) unknown reasons, I'll try and see if I can set up a systematic >> way to collect reliable data. > > Yes, please do. I'm guessing there's some factor here that is > important to consider. I wrote a simple-minded measurement routine that can at least report the time taken between successive character insertions, and I noticed that better alternatives have been brought up in response to my other mailing list thread (titled "Latency profiling?"). I haven't had time to prepare a systematic test case yet, but I will look into it when I get home from work this evening. - command-execute 5676 73% - call-interactively 5676 73% - funcall-interactively 5676 73% - self-insert-command 5080 66% - lsp-on-change 2144 27% - lsp--text-document-content-change-event 1964 25% - lsp--point-to-position 1964 25% line-number-at-pos 1964 25% + json-encode 164 2% + file-truename 16 0% - c-after-change 1784 23% - mapc 1772 23% + # 1772 23% - c-invalidate-sws-region-after 12 0% - c-invalidate-sws-region-after-ins 12 0% - c-beginning-of-macro 8 0% back-to-indentation 4 0% - c-literal-limits 4 0% c-state-full-pp-to-literal 4 0% - lsp-before-change 1016 13% - lsp--point-to-position 1016 13% line-number-at-pos 1016 13% - sp--post-self-insert-hook-handler 56 0% - sp-insert-pair 28 0% - sp--pair-to-insert 24 0% - sp--all-pairs-to-insert 20 0% - sp--looking-back-p 8 0% sp--looking-back 8 0% + sp--do-action-p 8 0% + sp--get-closing-regexp 4 0% + sp--all-pairs-to-insert 16 0% + sp-escape-open-delimiter 12 0% + c-before-change 28 0% - jit-lock-after-change 4 0% + run-hook-with-args 4 0% + counsel-M-x 360 4% + evil-open-below 232 3% - lsp-ui-doc--make-request 643 8% line-number-at-pos 627 8% + file-truename 8 0% url-hexify-string 4 0% - lsp-ui-sideline 528 6% line-number-at-pos 528 6% + timer-event-handler 327 4% + evil-escape-pre-command-hook 220 2% + # 141 1% + redisplay_internal (C function) 88 1% + ... 29 0% + yas--post-command-handler 20 0% + global-spacemacs-whitespace-cleanup-mode-check-buffers 4 0% + internal-timer-start-idle 4 0% + flycheck-display-error-at-point-soon 4 0% flycheck-error-list-update-source 4 0%