[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of the overlay tree branch?
From: |
Sebastian Sturm |
Subject: |
Re: State of the overlay tree branch? |
Date: |
Sun, 18 Mar 2018 22:04:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
I also found it surprising that overlays would slow down line counting,
but since I don't know anything about the architecture of the Emacs
display engine, or its overlay implementation, I figured that overlays
must be to blame because
(i) the issue went away after switching to the feature/noverlay branch
(ii) configuring the semantic highlighter to use its font-lock backend
also resolved the performance issue (though with the font-lock backend,
highlights are easily messed up by editing operations which makes the
overlay variant far more appealing)
I also found that some other heavy users of overlays such as
avy-goto-word-0-{above,below} feel faster with the feature/noverlay
branch, so I'd welcome a merge of the overlay branch even if there was a
technically superior alternative to line-number-at-pos that didn't
suffer from overlay-related performance issues.
That being said, your suggestion sounds intriguing. What would be
required to expose find_newline to Lisp? Would I simply have to wrap it
in one of Emacs's DEFINE_<something> macros? Is there some documentation
on the Emacs C backend?
On 03/18/2018 09:39 PM, Eli Zaretskii wrote:
>> From: Sebastian Sturm <address@hidden>
>> Date: Sun, 18 Mar 2018 21:14:53 +0100
>>
>> [1] I'm using cquery for my C++ editing needs, which comes with an
>> overlay-based semantic highlighting mechanism. With my emacs
>> configuration, lsp-mode/lsp-ui emit 6 calls to line-number-at-pos per
>> character insertion, which consume ~20 to 25 ms each when performing
>> edits close to the bottom of a 66KB C++ file (measured using
>> (benchmark-run 1000 (line-number-at-pos (point))) on a release build of
>> emacs-27/git commit #9942734...). Using the noverlay branch, this figure
>> drops to ~160us per call.
>
> If lsp-mode/lsp-ui needs a fast line counter, one can easily be
> provided by exposing find_newline to Lisp. IME, it's lightning-fast,
> and should run circles around count-lines (used by line-number-at-pos).
>
> (I'm not sure I even understand how overlays come into play here,
> btw.)
- State of the overlay tree branch?, Sebastian Sturm, 2018/03/18
- Re: State of the overlay tree branch?, Eli Zaretskii, 2018/03/18
- Re: State of the overlay tree branch?,
Sebastian Sturm <=
- Re: State of the overlay tree branch?, Sebastian Sturm, 2018/03/18
- Re: State of the overlay tree branch?, Sebastian Sturm, 2018/03/18
- Re: State of the overlay tree branch?, Eli Zaretskii, 2018/03/19
- Re: State of the overlay tree branch?, Sebastian Sturm, 2018/03/19
- Re: State of the overlay tree branch?, Eli Zaretskii, 2018/03/19
- Re: State of the overlay tree branch?, Stefan Monnier, 2018/03/19
- Re: State of the overlay tree branch?, Sebastian Sturm, 2018/03/19
- Re: State of the overlay tree branch?, Stefan Monnier, 2018/03/19
- Re: State of the overlay tree branch?, Sebastian Sturm, 2018/03/19
- Re: State of the overlay tree branch?, Eli Zaretskii, 2018/03/20