From: Sebastian Sturm <s.sturm@arkona-technologies.de>
To: emacs-devel@gnu.org
Subject: Re: State of the overlay branch (again)?
Date: Wed, 25 Sep 2019 22:02:18 +0200 [thread overview]
Message-ID: <343fb797-6ef8-8e10-1153-394537a93b52@arkona-technologies.de> (raw)
In-Reply-To: <jwvftkka79s.fsf-monnier+emacs@gnu.org>
sure. Opening one of my somewhat larger C++ source files (~2300 lines,
which produces close to 4000 semantic highlighting overlays), I
repeatedly created new lines using Spacemacs's default 'o' keybinding (I
guess vanilla Emacs wouldn't behave differently in this respect though I
didn't try). Doing that at different positions within the buffer (while
keeping those positions roughly identical from run to run, though both
my personal perception and the resulting timing data suggest that
position doesn't matter), elp-instrument-function told me that a recent
build of emacs 27 (git commit #52172d23401) takes close to half a second
to open a single newline (which matches what I'm seeing on screen during
editing):
Function Name Call Count Elapsed Time Average Time
emacs-27: evil-open-below 7 2.877079901 0.4110114144
Removing all overlays using (remove-overlays) while leaving
semantic-highlighting enabled (i.e., any new highlights sent by clangd
would still be processed and converted into overlays during editing)
resulted in the following profile:
emacs-27 [overlays cleared]: evil-open-below 7 0.0555971120 0.0079424445
By comparison, this is what I get using the noverlay branch (same file,
same number of overlays, 3774):
emacs-noverlay: evil-open-below 7 0.058601084 0.0083715834
and, for comparison, with all overlays removed:
emacs-noverlay: [overlays cleared]: evil-open-below 9 0.03571364
0.0039681822
On 9/25/19 2:32 PM, Stefan Monnier wrote:
>> (https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00565.html)
>> because overlays are heavily used by some implementations of semantic
>> highlighting (see emacs-ccls, lsp-mode).
> [...]
>> If so, is there anything I could do to help speed up the
>> merge process?
>
> I think benchmarks comparing the noverlay branch with master
> (especially on those problematic cases) could do wonders to motivate
> someone to finish the development&merge (assuming the benchmarks show
> that it improves performance significantly, of course).
>
>
> Stefan
>
prev parent reply other threads:[~2019-09-25 20:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 7:59 State of the overlay branch (again)? Sebastian Sturm
2019-09-25 8:58 ` Eli Zaretskii
2019-09-25 12:07 ` Sebastian Sturm
2019-09-25 12:32 ` Stefan Monnier
2019-09-25 20:02 ` Sebastian Sturm [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=343fb797-6ef8-8e10-1153-394537a93b52@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.