(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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4