Doom-emacs: Overlays/text properties and performance

Created on 1 Mar 2020  路  3Comments  路  Source: hlissner/doom-emacs

I'm opening this meta-issue because I think it should be of interest to many doom users:

when having many overlays (or, I assume, text properties) within a buffer, (field-beginning) and (field-end) can be extremely slow. Which is bad news because evil-mode uses these calls on a regular basis (see https://github.com/emacs-evil/evil/issues/1281). We might want to have large numbers of overlays or text properties to replace Emacs's builtin font-lock mechanism by lsp-provided semantic highlighting (supported at least for C++ via clangd and for java), or by tree-sitter (https://github.com/th0rex/emacs-tree-sitter/tree/my_highlight). For C++ this improves highlighting accuracy and allows users to disable cc-mode entirely (which in my experience has its own share of performance problems as it tries to heuristically infer user-defined types and probably some other stuff).

also, lsp--position-to-point is significantly slowed down by overlays due to (line-end-position) checking field boundaries by default. I'm slightly repurposing a PR to lsp-mode to disable field boundary checking (https://github.com/emacs-lsp/lsp-mode/pull/1464) so everyone please feel free to try that PR and see if it breaks anything

Edit: I meant clangd-based highlighting improves accuracy compared to cc-mode, not compared to the semantic highlighting provided by ccls (which should also suffer from fewer performance drawbacks if the font-lock backend is used)

question performance

Most helpful comment

I created a playground fork of evil at sebastiansturm/evil that defines a buffer-local variable evil-suppress-field-narrowing. This variable can be set to t in buffers that make heavy use of overlays and/or text properties. Which obviously is no proper fix but at least can be used to assess the damage done by ignoring field boundaries. The performance of o/O/dd is massively improved in buffers that use overlay-backed semantic highlighting

All 3 comments

simply removing evil-narrow-to-field doesn't fix the performance problems I'm seeing with evil-open-below and evil-open-above so I guess I'll have to take a closer look

or actually I think it does, I had initially missed the evil-narrow-to-field calls within doom's autoload/advice.el

I created a playground fork of evil at sebastiansturm/evil that defines a buffer-local variable evil-suppress-field-narrowing. This variable can be set to t in buffers that make heavy use of overlays and/or text properties. Which obviously is no proper fix but at least can be used to assess the damage done by ignoring field boundaries. The performance of o/O/dd is massively improved in buffers that use overlay-backed semantic highlighting

Was this page helpful?
0 / 5 - 0 ratings