mirror of
https://github.com/zed-industries/zed.git
synced 2025-01-14 22:14:23 +00:00
f7a86967fd
Fixes https://github.com/zed-industries/zed/issues/9575 Fixes https://github.com/zed-industries/zed/issues/4294 ### Problem When a large git repository's `.git` folder changes (due to a `git commit`, `git reset` etc), Zed needs to recompute the git status for every file in that git repository. Part of computing the git status is the *unstaged* part - the comparison between the content of the file and the version in the git index. In a large git repository like `chromium` or `linux`, this is inherently pretty slow. Previously, we performed this git status all at once, and held a lock on our `BackgroundScanner`'s state for the entire time. On my laptop, in the `linux` repo, this would often take around 13 seconds. When opening a file, Zed always refreshes the metadata for that file in its in-memory snapshot of worktree. This is normally very fast, but if another task is holding a lock on the `BackgroundScanner`, it blocks. ### Solution I've restructured how Zed handles Git statuses, so that when a git repository is updated, we recompute files' git statuses in fixed-sized batches. In between these batches, the `BackgroundScanner` is free to perform other work, so that file operations coming from the main thread will still be responsive. Release Notes: - Fixed a bug that caused long delays in opening files right after performing a commit in very large git repositories. |
||
|---|---|---|
| .. | ||
| connection_manager.rs | ||
| debounced_delay.rs | ||
| lsp_command.rs | ||
| lsp_ext_command.rs | ||
| prettier_support.rs | ||
| project.rs | ||
| project_settings.rs | ||
| project_tests.rs | ||
| search.rs | ||
| search_history.rs | ||
| task_inventory.rs | ||
| terminals.rs | ||