From: Sebastian Sturm <s.sturm@arkona-technologies.de>
To: emacs-devel@gnu.org
Subject: Re: State of the overlay tree branch?
Date: Mon, 19 Mar 2018 10:53:52 +0100 [thread overview]
Message-ID: <f3216876-e29c-a163-bd7e-102574a28ff7@arkona-technologies.de> (raw)
In-Reply-To: <83vadso9ad.fsf@gnu.org>
On 03/19/2018 07:43 AM, Eli Zaretskii wrote:
>> From: Sebastian Sturm <s.sturm@arkona-technologies.de>
>> 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%
+ #<compiled 0x1a24bed> 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%
+ #<compiled 0xb54291> 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%
next prev parent reply other threads:[~2018-03-19 9:53 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-18 20:14 State of the overlay tree branch? Sebastian Sturm
2018-03-18 20:39 ` Eli Zaretskii
2018-03-18 21:04 ` Sebastian Sturm
2018-03-18 23:03 ` Sebastian Sturm
2018-03-18 23:20 ` Sebastian Sturm
2018-03-19 6:43 ` Eli Zaretskii
2018-03-19 9:53 ` Sebastian Sturm [this message]
2018-03-19 12:57 ` Eli Zaretskii
2018-03-19 14:56 ` Stefan Monnier
2018-03-19 15:07 ` Sebastian Sturm
2018-03-19 15:13 ` Stefan Monnier
2018-03-20 1:23 ` Sebastian Sturm
2018-03-20 6:30 ` Eli Zaretskii
2018-03-21 0:36 ` Sebastian Sturm
2018-03-21 6:47 ` Eli Zaretskii
2018-03-22 13:16 ` Stefan Monnier
2018-03-22 19:54 ` Sebastian Sturm
2018-03-22 20:04 ` Sebastian Sturm
2018-03-22 20:52 ` Stefan Monnier
2018-03-22 23:11 ` Sebastian Sturm
2018-03-23 5:03 ` Stefan Monnier
2018-03-23 12:25 ` Sebastian Sturm
2018-03-23 12:47 ` Eli Zaretskii
2018-03-23 13:19 ` Stefan Monnier
2018-03-23 13:37 ` Noam Postavsky
2018-03-23 13:55 ` Stefan Monnier
2018-03-23 14:22 ` Eli Zaretskii
2018-03-23 14:39 ` Stefan Monnier
2018-03-23 19:39 ` Stefan Monnier
2018-03-25 15:11 ` Stefan Monnier
2018-03-25 16:39 ` Eli Zaretskii
2018-03-25 17:35 ` Stefan Monnier
2018-03-23 8:07 ` Eli Zaretskii
2018-03-23 9:08 ` Eli Zaretskii
2018-03-23 10:15 ` Sebastian Sturm
2018-03-23 12:39 ` Eli Zaretskii
2018-03-23 12:12 ` Stefan Monnier
2018-03-23 12:40 ` Eli Zaretskii
2018-03-23 12:55 ` Stefan Monnier
2018-03-19 6:36 ` Eli Zaretskii
2018-03-19 6:28 ` Eli Zaretskii
2018-03-21 14:14 ` Sebastien Chapuis
2018-03-21 15:35 ` Eli Zaretskii
2018-03-26 13:06 ` Stefan Monnier
2018-03-27 20:59 ` Sebastian Sturm
[not found] <<c24f8534-5245-026e-da18-f6be7b9702bf@arkona-technologies.de>
[not found] ` <<834lldp18f.fsf@gnu.org>
2018-03-18 21:37 ` Drew Adams
2018-03-19 1:33 ` Stefan Monnier
2018-03-19 6:50 ` Eli Zaretskii
2018-03-19 12:29 ` Stefan Monnier
2018-03-19 13:02 ` Eli Zaretskii
2018-03-19 13:43 ` Stefan Monnier
2018-03-19 14:28 ` Eli Zaretskii
2018-03-19 14:39 ` Stefan Monnier
2018-03-19 6:33 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f3216876-e29c-a163-bd7e-102574a28ff7@arkona-technologies.de \
--to=s.sturm@arkona-technologies.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).