search

cquery-project / emacs-cquery

Emacs client for cquery, a low-latency language server supporting multi-million line C++ code-bases
116 stars 14 forks source link

Spurious performance issues with semantic-highlighting #28

Closed sebastiansturm closed 6 years ago

sebastiansturm commented 6 years ago

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

sebastiansturm commented 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)

jacobdufault commented 6 years ago

Mind adding this information to https://github.com/cquery-project/cquery/wiki/Emacs?

sebastiansturm commented 6 years ago

sure, will do this when I get home from work.

MaskRay commented 6 years ago

@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

sebastiansturm commented 6 years ago

@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?