[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of the overlay branch (again)?
From: |
Sebastian Sturm |
Subject: |
Re: State of the overlay branch (again)? |
Date: |
Wed, 25 Sep 2019 22:02:18 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
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