Re: State of the overlay branch (again)?

[Sebastian Sturm <s.sturm@arkona-technologies.de>]

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
>