expensive "git status" polling even with all git features disabled

[TPolzer]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

I disabled all git related features, following

• https://github.com/zed-industries/zed/issues/13304

Unfortunately zed seems to poll a subprocess git --no-optional-locks status --porcelain=v1 --untracked-files=all -z . that uses significant amounts of CPU.

Running git --no-optional-locks status --porcelain=v1 --untracked-files=all -z . in the project root takes around 100ms, which is probably expected, since my repo is large. It would be nice to be able to just turn off git integration or ideally configure a polling frequency for polled (expensive) state?

Environment

Zed: v0.143.7 (Zed) OS: Linux Wayland debian unknown Memory: 31 GiB Architecture: x86_64

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

No response

If applicable, attach your Zed.log file to this issue.

Zed.log

[notpeter]

There was one more missing from the list on #13304 (I added it just now):

  "outline_panel": {
    "git_status": false
  },

Can add that and let me know if that completely quiesces all git status activity?

[SomeoneToIgnore]

That would not change much, as there's a project panel and tabs having the same setting at least.

[TPolzer]

Would it be an option to place an inotify watch on the git root to know when to refresh git status?

[joshuawarner32]

I'm running into a much more extreme version of this, on a very large internal repo (~500k tracked files!). In my case, the current behavior of periodically running this git status command makes zed basically unusable for any period of time on battery. Each invocation of this git status command takes 7-10 seconds, spiking to 100% CPU each time, and then very shortly later spiking CPU again.

I've essentially 100% switched back to VS Code when developing on said repo, since I strongly prefer not having my lap get hot if I'm not actively compiling/etc.

[joshuawarner32]

This patch seems to work for me:

diff --git a/crates/worktree/src/worktree.rs b/crates/worktree/src/worktree.rs
index 0461db4bf7..4084ee7511 100644
--- a/crates/worktree/src/worktree.rs
+++ b/crates/worktree/src/worktree.rs
@@ -4467,6 +4467,7 @@ impl BackgroundScanner {

     /// Update the git statuses for a given batch of entries.
     fn update_git_statuses(&self, job: UpdateGitStatusesJob) {
+        return;
         log::trace!("updating git statuses for repo {:?}", job.work_directory.0);
         let t0 = Instant::now();
         let Some(statuses) = job.repository.statuses(Path::new("")).log_err() else {

I don't really use/want git anything in my editor TBH, so not much lost.

[joshuawarner32]

Would zed folks be open to a patch that adds a default-off "git": {"disable_status_updates": true} config (or whatever)?

[rtfeldman]

@joshuawarner32 Yeah, that sounds good! 😃

If you can make a PR for it, can you @mention me in it so I can follow up?

[github-actions[bot]]

Hi there! 👋 We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. If you are able to reproduce this issue in the latest version of Zed, please let us know by commenting on this issue, and we will keep it open. If you can't reproduce it, feel free to close the issue yourself. Otherwise, we'll close it in 7 days. Thanks for your help!

[notpeter]

@joshuawarner32 Can you confirm that this is still an issue (I would assume so).

[joshuawarner32]

I haven't noticed this particular issue recently, I suspect related to the upgrade to use the system git binary instead of the bundled one (or perhaps other changes; not sure).

[pbsds]

I am still very much affected by this, to the point where my system gets noticeably sloggish whenever i open a new zed window in a new nixpkgs worktree. If launching git is unavoidable, would it help if we could configure a niceness value or set a limited cpu affinity for all launched subprocesses? I think that would prove valuable for LSPs like rust-analyzer too

[jacobmichels]

I am also affected by this. In large repositories my battery is consumed quickly with zed open.

edit: while I am seeing problems with resource usage within large repos, I don't think it's due to git status polling, which as far as I can tell is not something that zed does anymore. After inserting a print statement in git::repository::RealGitRepository.status, I realized that git status is only ran when a change to the repo occurs.

[pbsds]

I think this could be reopened. The problem could be largely fixed by doing a single git status when opening zed rather than check each file separately

[mehdi-pplx]

agh still being plagued by this, with it actually resulting in a broken git repo because Zed seemingly used a different copy of git on my system (the one at /Applications/Xcode.app/Contents/Developer/usr/bin/git)

[Be-ing]

I just opened the Chromium Git repository in Zed, which has a 59 GB .git directory and I can't even let clangd index the project because my CPU is bogged down by these git status processes.