Is my problem eglot or clangd?

[vincentjgoh]

So I'm struggling with huge stalls (30-60s, sometimes more) from using eglot + clangd. I thought I had it figured out, but I guess I don't.

I'm using eglot basically stock out of the box; I haven't seen anything that seems worthwhile configuring. I've turned off hover-info, and I've tried to disable flymake (it spits out mostly incorrect errors, honestly).

My project is huge. It's an Unreal Engine project, and there are a lot of files. The compile_commands.json is 700+MB (most of it is flags, though, and a lot of them are duplicates), but it mostly works. clangd is currently taking up about 6GB of memory (1GB working) on my Windows 10 machine.

But if I open up the events buffer, there's almost always something compiling. File after file after file, even files that haven't changed since I last saw them go by in the events buffer. I added a .clangd to my dev directory (and I believe it's being picked up; clangd uses config files by default, as near as I can tell, and I've used --check= on the command line to make sure there's nothing bad in it).

Because there are so many files compiling, I thought maybe I could get around that by adding

CompileFlags:
    Remove: -W*

Diagnostics:
    Suppress: '*'

Index:
    Background: Skip
    External:
	    File: d:\p4v\Dev\clangd.dex

to my .clangd file. No real change, still huge hitches all the time. FWIW, the clangd.dex file is about 315MB. I have NO idea if clangd is using it properly (if I'm honest, the clangd documentation is a nightmare; it's so bare-bones and is absolutely not helpful in a case like this).

Edit:

[stderr] I[09:28:34.687] --> reply:textDocument/signatureHelp(115) 5260 ms
[server-notification] Wed Aug 17 09:28:46 2022:
(:jsonrpc "2.0" :method "textDocument/publishDiagnostics" :params
		  (:diagnostics
		   []
		   :uri "file:///d:/p4v/Dev/Source/Team/Team.cpp" :version 0))
[stderr] I[09:28:46.179] --> textDocument/publishDiagnostics

(Does this show that the .clangd is being ignored? Diagnostics are supposed to be off.)

So I suppose the question is whether this is an issue I'm having with clangd being pathological, or eglot making unnecessary requests. I love the functionality, but having the whole editor stall when I'm halfway through a line, or right after I save or any other number of somewhat random times is completely untenable, and I can't believe that this is the experience everyone else is having. I've had emacs stall while I was typing out a COMMENT in a header file. That can't possibly be normal behaviour.

If anyone has any help, I'd really appreciate it.

[vincentjgoh]

Oh, also, I think it might be worth having an option to pause any requests while a compile is happening. I've launched a long build only to see clangd chewing through files in the background, which seems counter-productive.

[joaotavora]

Let's take measurements first and take measures after.

[joaotavora]

vincentjgoh ***@***.***> writes:

So I suppose the question is whether this is an issue I'm having with clangd being pathological, or eglot making unnecessary requests.

A poor-man's way to tell what's eating up your CPU and your time is to glance at 'top's output on another terminal window. If you see the 'emacs' program peaking over `clangd`, then something in Emacs -- possibly but not necessarily -- Eglot, is the culprit. Yet another way is to use M-x profiler-start, M-x profiler-stop and M-x profiler-report and post the expanded relevant portion of the results in this thread.

I love the functionality, but having the whole editor stall when I'm halfway through a line, or right after I save or any other number of somewhat random times is completely untenable, and I can't believe that this is the experience everyone else is having. I've had emacs stall while I was typing out a COMMENT in a header file. That can't possibly be normal behaviour.

No, it isn't. But don't assume comments aren't somehow relevant to the LSP server, they are. In particular, clangd can work with the clang-tidy tool, which is generally aware of rule activation/deactivation directives that are encoded in comments. I use Eglot and clangd very successfully, though not with "monstruous" projects. However, including header files with lots of templates does mean that my compilation times are non-trivial. But my editing experience isn't extremely degraded. And I don't turn off any default feature of Eglot, though I do happen to use a particularly lean and vanilla configuration. So your problem could come down to a number of things: * Eglot making too many requests because you've set some variable like eglot-send-changes-idle-time or eldoc-idle-delay too low. * You're using some other eager thing like company-mode and it also makes "idle-time" requests in the (pseudo-)background controled by company-idle-delay. * The printing of log information to *EGLOT (project/c++-mode) events* is costing a lot of time and memory. In this case you might have luck setting eglot-events-buffer-size to 0. * You're using some other greedy extension in Emacs, be sure to conduct any tests using a controlled `emacs -Q` run. As usual, the only way to tell is to conduct measurements, so be sure to send some `M-x profiler-report` output this way. FWIW's here's a typical profile from 2-3 minutes editing in a C++ project. As you can see Eglot's code isn't even on the map. But c++-mode's fontification code is, though not in a show-stopping way. c++-mode is notoriously complex and slow (and buggy), maybe someday we'll get to replace it with something better. João

[joaotavora]

Please expand this line

1,856,014,573 59% + #<compiled -0x1ae40cf16d13c42b>

The biggest chunk of Elisp time is being spend sending the context of the file to the server after save, it seems. Saving a buffer however is an occasional action, not like typing characters into a buffer.

Please be very clear about what actions exactly you performed between the time of M-x profiler-start and the time of M-x profiler-stop.

Please also try with eglot-events-buffers-size set to 0.

[vincentjgoh]

I'll do that all presently, though I'd like to mention that I had to edit some deep engine files in the project, and my clangd is currently taking up 75% of my CPU and 42GB of memory despite the fact that I'm not actively editing anything anymore. It briefly peaked its memory usage at 50GB, but the CPU usage was down to 25% at that point.

[vincentjgoh]

  1,958,132,691  63% - command-execute
  1,889,305,220  61%  - funcall-interactively
  1,859,026,763  60%   - save-buffer
  1,859,026,763  60%    - basic-save-buffer
  1,858,646,825  60%     - run-hooks
  1,856,209,743  59%      - eglot--signal-textDocument/didSave
  1,856,014,573  59%       - jsonrpc-notify
  1,856,014,573  59%        - jsonrpc-connection-send
  1,856,014,573  59%         - apply
  1,856,014,573  59%          - #<compiled -0x1ae40cf16d13c42b>
     36,271,081   1%           - process-send-string
     36,193,271   1%            - internal-default-process-filter
     27,361,383   0%             - #<compiled 0x1fa8af6bdbd6a339>
          1,649   0%                line-beginning-position
         64,793   0%            - jsonrpc--process-filter
         61,025   0%             - jsonrpc-connection-receive
         36,889   0%              - #<compiled -0xd98af4b9f55e46c>
         36,889   0%               - apply
         36,889   0%                - eglot-handle-notification
         36,889   0%                 - apply
         36,889   0%                  - #<compiled 0xfe0f1c02cdbdad7>
         23,888   0%                   + find-buffer-visiting
         11,840   0%                   + eglot--uri-to-path
          1,056   0%                   + eglot--check-object
             85   0%                     #<compiled -0x9de98e34fd5d35d>
             20   0%                   + eglot--range-region
         24,136   0%              + jsonrpc--log-event
          1,056   0%               #<compiled -0x1de56117c0c1b097>
          9,849   0%            + timer-event-handler
        589,860   0%           - jsonrpc--log-event
        378,616   0%            - pp-to-string
         12,376   0%             - pp-buffer
         12,376   0%              + indent-sexp
          1,056   0%               #<compiled -0x1de5613dbcf5f097>
        139,448   0%             jsonrpc--json-encode
        105,954   0%       - eglot--signal-textDocument/didChange
         84,666   0%        - jsonrpc-notify
         84,666   0%         - jsonrpc-connection-send
         84,666   0%          - apply
         84,666   0%           - #<compiled -0x1ae40cf16d13c42b>
         81,504   0%            + jsonrpc--log-event
         20,232   0%        - eglot--VersionedTextDocumentIdentifier
         20,232   0%         - eglot--TextDocumentIdentifier
         20,232   0%          - eglot--path-to-uri
         12,376   0%           - url-hexify-string
         12,376   0%            + mapconcat
          7,344   0%           + file-truename
         21,816   0%       + eglot--TextDocumentIdentifier

[vincentjgoh]

Actually, I'll have to do those actions later; I had to kill clangd; my compile couldn't allocate enough memory to use any more than 1 process instead of the regular 8.

Thanks so much for all your help so far!

[vincentjgoh]

In the end, I don't think it had anything to do with Eglot OR clang. I stripped my emacs down to the bare bones and built it up bit by bit, and the problem is gone. It was honestly VSCode that tipped me off that something was amiss, because it was incredibly fast using the exact same clang index.

[joaotavora]

I don't think it had anything to do with Eglot OR clang. I stripped my emacs down to the bare bones and built it up bit by bit, and the problem is gone.

No problem. A configuration issue, as is frequent.