Diagnostics toggle warning triggers high CPU usage and LSP becomes irresponsive

[nvinuesa]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

When using zed with a fairly big Go codebase (https://github.com/juju/juju), and having a lot of warning diagnostics and a few error diagnostics, if I run the command diagnostics: toggle warnings then the editor gets to high CPU usage and the LSP becomes irresponsive.

This is what Zed's logs show:

2024-10-02T22:23:24.562584666+02:00 [INFO] Initializing default prettier with plugins {}
2024-10-02T22:23:24.581732099+02:00 [INFO] Initializing default prettier with plugins {}
2024-10-02T22:23:24.595611402+02:00 [INFO] Initializing default prettier with plugins {}

in a loop.

There are no logs in gopls even though I added the -logfile flag.

Environment

Zed: v0.155.2 (Zed)
OS: Linux Wayland ubuntu 24.04
Memory: 15.3 GiB
Architecture: x86_64
GPU: Intel(R) UHD Graphics 620 (WHL GT2) || Intel open-source Mesa driver || Mesa 24.0.9-0ubuntu0.1

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

Zed.log

2024-10-02T22:23:47.67160683+02:00 [INFO] Initializing default prettier with plugins {}

2024-10-02T22:23:47.685847379+02:00 [INFO] Initializing default prettier with plugins {}

2024-10-02T22:23:47.697461186+02:00 [INFO] Initializing default prettier with plugins {}

2024-10-02T22:23:47.712111975+02:00 [INFO] Initializing default prettier with plugins {}

2024-10-02T22:23:47.721675912+02:00 [INFO] Initializing default prettier with plugins {}

2024-10-02T22:23:47.73568399+02:00 [INFO] Initializing default prettier with plugins {}

[notpeter]

I was able to hang Zed Preview 0.156.0
running gopls 0.16.2 installed via homebrew
with the following steps:

cd ~/source
git clone https://github.com/juju/juju
cd juju
zed . doc.go

Wait till gopls loaded and then tried to click on the diagnostic panel and it hung.

My log included the following:

2024-10-04T16:38:07.39745-04:00 [INFO] attempting to start language server "gopls", path: "/Users/peter/source/juju", id: 1
2024-10-04T16:38:07.397834-04:00 [INFO] Initializing default prettier with plugins {}
2024-10-04T16:38:07.39928-04:00 [INFO] found user-installed language server for gopls. path: "/opt/homebrew/bin/gopls", arguments: ["-mode=stdio"]
2024-10-04T16:38:07.399382-04:00 [INFO] using project environment for language server LanguageServerName("gopls")
2024-10-04T16:38:07.39949-04:00 [INFO] starting language server process. binary path: "/opt/homebrew/bin/gopls", working directory: "/Users/peter/source/juju", args: ["-mode=stdio"]
2024-10-04T16:38:07.415289-04:00 [INFO] Opening main db
2024-10-04T16:38:52.26819-04:00 [INFO] Initializing default prettier with plugins {}
2024-10-04T16:38:54.744314-04:00 [WARN] unhandled capability registration: Registration { id: "workspace/didChangeConfiguration", method: "workspace/didChangeConfiguration", register_options: None }
2024-10-04T16:39:02.807956-04:00 [ERROR] MDB_MAP_FULL: Environment mapsize limit reached
2024-10-04T16:39:02.809791-04:00 [INFO] Summarizing updated entries took 4.125µs
2024-10-04T16:39:08.096294-04:00 [ERROR] Suspected hang on main thread:
zed[529e32f8f3cca1fe]::reliability::monitor_main_thread_hangs::handle_backtrace_signal::handle_sigusr2
__simple_esappend
__pthread_cond_wait
<parking[9e5c3a2bc4a02fa]::Inner>::park
<gpui[5f28f27b0d776c08]::platform::mac::dispatcher::MacDispatcher as gpui[5f28f27b0d776c08]::platform::PlatformDispatcher>::park
<gpui[5f28f27b0d776c08]::executor::Scope as core[f827f14b5e761a5d]::ops::drop::Drop>::drop
core[f827f14b5e761a5d]::ptr::drop_in_place::<gpui[5f28f27b0d776c08]::executor::Scope>
core[f827f14b5e761a5d]::ptr::drop_in_place::<<semantic_index[7fade3b0ce30182e]::embedding_index::EmbeddingIndex>::chunk_files::{closure#0}::{closure#0}>
<async_task[3f1cb45a7eb7a0e6]::raw::RawTask<<async_task[3f1cb45a7eb7a0e6]::runnable::Builder<_>>::spawn_local::Checked<core[f827f14b5e761a5d]::pin::Pin<alloc[47bc6d386d7ae45f]::boxed::Box<dyn core[f827f14b5e761a5d]::future::future::Future<Output = core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>>>>>, core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>, <gpui[5f28f27b0d776c08]::executor::ForegroundExecutor>::spawn::inner<core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>>::{closure#0}, ()>>::run
gpui[5f28f27b0d776c08]::platform::mac::dispatcher::trampoline
<gpui[5f28f27b0d776c08]::platform::mac::platform::MacPlatform as gpui[5f28f27b0d776c08]::platform::Platform>::run
<gpui[5f28f27b0d776c08]::app::App>::run::<zed[529e32f8f3cca1fe]::main::{closure#5}>
zed[529e32f8f3cca1fe]::main
std[4f7d7c3ef984657a]::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
std[4f7d7c3ef984657a]::rt::lang_start::<()>::{closure#0}
std::rt::lang_start_internal::hdd117cb81a316264
_main

I then killed and reopened Zed. It got a little further, showing me some number of errors (23?) which I was able to click into the diagnostics panel and briefly see in the multibuffer before it hung again with:

2024-10-04T16:42:54.47476-04:00 [ERROR] MDB_MAP_FULL: Environment mapsize limit reached
2024-10-04T16:42:54.474903-04:00 [INFO] Summarizing updated entries took 3µs
2024-10-04T16:42:59.127896-04:00 [ERROR] Suspected hang on main thread:
zed[529e32f8f3cca1fe]::reliability::monitor_main_thread_hangs::handle_backtrace_signal::handle_sigusr2
__simple_esappend
__pthread_cond_wait
<parking[9e5c3a2bc4a02fa]::Inner>::park
<gpui[5f28f27b0d776c08]::platform::mac::dispatcher::MacDispatcher as gpui[5f28f27b0d776c08]::platform::PlatformDispatcher>::park
<gpui[5f28f27b0d776c08]::executor::Scope as core[f827f14b5e761a5d]::ops::drop::Drop>::drop
core[f827f14b5e761a5d]::ptr::drop_in_place::<gpui[5f28f27b0d776c08]::executor::Scope>
core[f827f14b5e761a5d]::ptr::drop_in_place::<<semantic_index[7fade3b0ce30182e]::embedding_index::EmbeddingIndex>::chunk_files::{closure#0}::{closure#0}>
<async_task[3f1cb45a7eb7a0e6]::raw::RawTask<<async_task[3f1cb45a7eb7a0e6]::runnable::Builder<_>>::spawn_local::Checked<core[f827f14b5e761a5d]::pin::Pin<alloc[47bc6d386d7ae45f]::boxed::Box<dyn core[f827f14b5e761a5d]::future::future::Future<Output = core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>>>>>, core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>, <gpui[5f28f27b0d776c08]::executor::ForegroundExecutor>::spawn::inner<core[f827f14b5e761a5d]::result::Result<(), anyhow[7235d837ddcd6144]::Error>>::{closure#0}, ()>>::run
gpui[5f28f27b0d776c08]::platform::mac::dispatcher::trampoline
<gpui[5f28f27b0d776c08]::platform::mac::platform::MacPlatform as gpui[5f28f27b0d776c08]::platform::Platform>::run
<gpui[5f28f27b0d776c08]::app::App>::run::<zed[529e32f8f3cca1fe]::main::{closure#5}>
zed[529e32f8f3cca1fe]::main
std[4f7d7c3ef984657a]::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
std[4f7d7c3ef984657a]::rt::lang_start::<()>::{closure#0}
std::rt::lang_start_internal::hdd117cb81a316264
_main

On subsequently opens Zed Preview was stable and responsive and I was able to gopls navigations (go to definition, etc) to jump around without issue.

If Zed isn't hanging for you, you might look at the LSP logs (ctrl-shift-p, "debug: show language server logs" and drill down to go-pls.

[osiewicz]

Ok, so I think this is the classic case of us getting bogged down in open buffers (kinda like #19022). gopls sends out "publishDiagnostics" notifications even when there are no diagnostics for a given file. This causes us to register a buffer, which is fine on it's own, but not when we do it for every .go file in existence just because the language server started up.
To make matters worse, when we do register a buffer, we also send out didOpen notification to gopls. It may or may not do some extra background processing based on that.

This is a really long-winded way of saying that we should probably not register a file for which we didn't get any diagnostics.

[filipwiech]

@osiewicz Would it also make sense to not send the didOpen LSP notification when the buffer is not actually opened by the user, even if some diagnostics were registered for it? I'm thinking about some cases from my projects, where server can send a lot of diagnostics spread across hundreds of files, even though realistically I only have about a dozen or so opened ones. 🤔

[osiewicz]

@filipwiech yes! we've had a discussion and we want to make multibuffers a bit more lightweight, which would involve not sending out didOpen for excerpts in mutlibuffer that were not interacted with. I don't have a timeline for this change, but we do want to make it (and land other improvements you've mentioned as well).

[ConradIrwin]

This should be improved by

• diagnostics: Improve performance with large # of diagnostics #20189.