Closed sebastiansturm closed 6 years ago
I think this can be closed as the root issue seems to have been found by Stefan Monnier (cf. the emacs-devel thread cited above). Anyone experiencing the same performance problems may want to heed the cquery wiki's advice of using the feature/noverlay branch, or as a last resort use (set-buffer-multibyte nil)
Mind adding this information to https://github.com/cquery-project/cquery/wiki/Emacs?
sure, will do this when I get home from work.
@sebastiansturm I'm currently using 'font-lock
and with https://github.com/cquery-project/emacs-cquery/commit/383656d3cb368481594fd7a13d0395a8640afbac and my sorting of ranges, the performance does not seem too bad.
I need to set fontified
to override current setting, and both face
and font-lock-face
to get text colored correctly.
For unknown issue, just setting font-lock-face
is insufficient, font-lock may prepend face
to the text property, and among face
and font-lock-face
, the one coming earlier takes precedence.
You may also be interested in https://github.com/cquery-project/emacs-cquery/issues/7 where someone and I have made several attempts to optimize the overlay approach, but I had to revert them as none of our attempt was successful (I'm not clear about the behavior of forward-line and forward-char) I was able to optimize the highlighting after I used a scan line algorithm to make ranges non-overlapping in the cquery server
@MaskRay that sounds interesting; how exactly do you measure the relative performance of different Emacs configurations?
Based on suggestions made in response to my 'Latency profiling?' post to the emacs-devel mailing list, I've played around with registering perf probes for several UI-related Emacs functions (I think one of them was called set_waiting_for_input
or something like that, could check when I'm back at my laptop), then using xdotool to simulate interactive input and evaluating the distribution of waiting time intervals between successive calls to set_waiting_for_input
.
From what I can tell so far, this seems to yield plausible results, but I'm also still seeing differences between xdotool and truly interactive editing that I haven't been able to track down exactly. For instance, the doc overlay provided by lsp-ui doc mode sometimes seems to briefly pop up while scrolling through a large chunk of source code (i.e., simply holding j or k pressed) while I've never seen this happen with xdotool.
Do you have a more systematic approach of measuring Emacs latency?
I'm currently trying to reproduce a performance issue with semantic highlighting that seems to be related to overlays and possibly their effect on
line-number-at-pos
. While I can reliably reproduce the issue on one of my employer's closed-source files, a similarly large file taken from the LLVM repository didn't exhibit any performance problems at all (see emacs-devel thread).Since overlay performance is a regular complaint among cquery users, I hope someone can provide me with a similarly troublesome open source file that I could use to prepare a reproducible test case