Inline blame for large files with long Git histories causes Zed to create more and more Git processes using >95% CPU

[izuzak]

Check for existing issues

• [x] Completed

Describe the bug / provide steps to reproduce it

I work in a large Git repository with a long history. In the repository, there is a large text file (1.8 MB) very similar to the CODEOWNERS file. This file has a long history: ~52_000 commits.

I noticed today that my whole system was becoming really slow, and when I opened the activity monitor -- I saw a bunch of Git processes all using 95% or more CPU. And I noticed that quitting Zed immediately killed those processes as well. After poking around a bit, I was able to reliably reproduce the problem by opening the problematic file in Zed -- it immediately starts creating Git processes which use a lot of CPU and they never complete (unless I quit Zed).

On a hunch, I disabled the inline blame feature in the settings, and that completely resolves the problem.

"git": {
    "inline_blame": {
        "enabled": false
    }
},

cc @maxbrunsfeld since you seem to enjoy fixing these types of problems, or at least read about them 😂

Environment

Zed: v0.141.2 (Zed Preview) OS: macOS 14.5.0 Memory: 64 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

Screenshots...

First noticed this:  And then this a bit later: 

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

No response

[notpeter]

How long does it take the CLI version of git blame to return on the same file? I have a test file in a big repo that takes ~2secs and Zed does fine.

Anything relevant in your logs when this happens?

[izuzak]

Many thanks for looking into this, @notpeter! 🙇

How long does it take the CLI version of git blame to return on the same file?

A while 😭 🙈

> time git blame SERVICEOWNERS

real    1m28.442s
user    1m22.084s
sys     0m3.308s

Anything relevant in your logs when this happens?

This is the only error I see:

...
2024-06-27T18:06:56+02:00 [ERROR] Suspected hang on main thread:
zed[5a6c495e3af4366f]::reliability::monitor_main_thread_hangs::handle_backtrace_signal::handle_sigusr2
__simple_esappend
__pthread_cond_wait
<parking_lot[596eb9362621cc8]::raw_mutex::RawMutex>::lock_slow
<gpui[125670a2e5b32f61]::platform::mac::dispatcher::MacDispatcher as gpui[125670a2e5b32f61]::platform::PlatformDispatcher>::unparker
<gpui[125670a2e5b32f61]::app::AppContext>::shutdown
<gpui[125670a2e5b32f61]::app::AppContext>::new::{closure#1}
gpui[125670a2e5b32f61]::platform::mac::platform::will_terminate
<gpui[125670a2e5b32f61]::platform::mac::platform::MacPlatform as gpui[125670a2e5b32f61]::platform::Platform>::run
<gpui[125670a2e5b32f61]::app::App>::run::<zed[5a6c495e3af4366f]::main::{closure#2}>
zed[5a6c495e3af4366f]::main
std[e84bc52996b8b382]::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
std[e84bc52996b8b382]::rt::lang_start::<()>::{closure#0}
std::rt::lang_start_internal::hecc68fef83c8f44d
_main
2024-06-27T18:07:04+02:00 [ERROR] crates/lsp/src/lsp.rs:730: oneshot canceled
2024-06-27T18:07:04+02:00 [ERROR] crates/lsp/src/lsp.rs:730: oneshot canceled
2024-06-27T18:07:04+02:00 [ERROR] crates/lsp/src/lsp.rs:730: oneshot canceled
2024-06-27T18:07:04+02:00 [ERROR] crates/lsp/src/lsp.rs:730: oneshot canceled
2024-06-27T18:07:04+02:00 [ERROR] crates/lsp/src/lsp.rs:730: oneshot canceled
2024-06-27T18:07:14+02:00 [INFO] ========== starting zed ==========
2024-06-27T18:07:14+02:00 [INFO] Opening main db
...

Let me know if there's anything else I can provide/collect/do 🙏

For me, I think it'd be enough if Zed detected somehow that this file+history is just too big for it to handle and then aborts doing the blame.

[notpeter]

Easy reproduction steps from this comment

git clone https://github.com/nixos/nixpkgs
cd nixpkgs
zed pkgs/top-level/all-packages.nix

This triggers: git blame --incremental --contents - pkgs/top-level/all-packages.nix which takes many minutes to run.