2024-02-27 00:09:22 +03:00
|
|
|
[package]
|
2024-03-11 21:35:27 +03:00
|
|
|
name = "worktree"
|
2024-02-27 00:09:22 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
|
edition = "2021"
|
|
|
|
|
publish = false
|
|
|
|
|
license = "GPL-3.0-or-later"
|
|
|
|
|
|
2024-03-11 21:35:27 +03:00
|
|
|
[lib]
|
|
|
|
|
path = "src/worktree.rs"
|
|
|
|
|
doctest = false
|
|
|
|
|
|
2024-03-05 20:01:17 +03:00
|
|
|
[lints]
|
|
|
|
|
workspace = true
|
|
|
|
|
|
2024-02-27 00:09:22 +03:00
|
|
|
[features]
|
|
|
|
|
test-support = [
|
|
|
|
|
"language/test-support",
|
|
|
|
|
"settings/test-support",
|
|
|
|
|
"text/test-support",
|
|
|
|
|
"gpui/test-support",
|
2024-07-24 01:01:05 +03:00
|
|
|
"http_client/test-support",
|
2024-02-27 00:09:22 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
[dependencies]
|
|
|
|
|
anyhow.workspace = true
|
|
|
|
|
clock.workspace = true
|
|
|
|
|
collections.workspace = true
|
|
|
|
|
fs.workspace = true
|
|
|
|
|
futures.workspace = true
|
|
|
|
|
fuzzy.workspace = true
|
|
|
|
|
git.workspace = true
|
|
|
|
|
gpui.workspace = true
|
|
|
|
|
ignore.workspace = true
|
|
|
|
|
language.workspace = true
|
|
|
|
|
log.workspace = true
|
|
|
|
|
parking_lot.workspace = true
|
2024-06-21 19:39:14 +03:00
|
|
|
paths.workspace = true
|
2024-02-27 00:09:22 +03:00
|
|
|
postage.workspace = true
|
|
|
|
|
rpc.workspace = true
|
|
|
|
|
schemars.workspace = true
|
|
|
|
|
serde.workspace = true
|
|
|
|
|
serde_json.workspace = true
|
|
|
|
|
settings.workspace = true
|
project search: Increase perf up to 10x by batching `git status` calls (#16936)
***Update**: after rebasing on top of
https://github.com/zed-industries/zed/pull/16915/ (that also changed how
search worked), the results are still good, but not 10x. Instead of
going from 10s to 500ms, it goes from 10s to 3s.*
This improves the performance of project-wide search by an order of
magnitude.
After digging in, @as-cii and I found that opening buffers was the
bottleneck for project-wide search (since Zed opens, parses, ... buffers
when finding them, which is something VS Code doesn't do, for example).
So this PR improves the performance of opening multiple buffers at once.
It does this by doing two things:
- It batches scan-requests in the worktree. When we search, we search
files in chunks of 64. Previously we'd handle all 64 scan requests
separately. The new code checks if the scan requests can be batched and
if so it, it does that.
- It batches `git status` calls when reloading the project entries for
the opened buffers. Instead of calling `git status` for each file, it
calls `git status` for a batch of files, and then extracts the status
for each file.
(It has to be said that I think the slow performance on `main` has been
a regression introduced over the last few months with the changes made
to project/worktree/git. I don't think it was this slow ~5 months ago.
But I also don't think it was this fast ~5 months ago.)
## Benchmarks
| Search | Before | After (without
https://github.com/zed-industries/zed/pull/16915) | After (with
https://github.com/zed-industries/zed/pull/16915)
|--------|--------|-------|------|
| `zed.dev` at `2b2a501192e78e`, searching for `<` (`4484` results) |
3.0s<br>2.9s<br>2.89s | 489ms<br>517ms<br>476ms | n/a |
| `zed.dev` at `2b2a501192e78e`, searching for `:` (`25886+` results) |
3.9s<br>3.9s<br>3.8s | 70ms<br>66ms<br>72ms | n/a |
| `zed` at `55dda0e6af`, searching for `<` (`10937+` results) |
10s<br>11s<br>12s | 500m<br>499ms<br>543ms | 3.4s<br>3.1s<br> |
(All results recorded after doing a warm-up run that would start
language servers etc.)
Release Notes:
- Performance of project-wide search has been improved by up to 10x.
---------
Co-authored-by: Antonio <antonio@zed.dev>
2024-08-27 12:59:59 +03:00
|
|
|
smallvec.workspace = true
|
2024-02-27 00:09:22 +03:00
|
|
|
smol.workspace = true
|
|
|
|
|
sum_tree.workspace = true
|
|
|
|
|
text.workspace = true
|
|
|
|
|
util.workspace = true
|
|
|
|
|
|
|
|
|
|
[dev-dependencies]
|
|
|
|
|
clock = {workspace = true, features = ["test-support"]}
|
|
|
|
|
collections = { workspace = true, features = ["test-support"] }
|
Avoid holding worktree lock for a long time while updating large repos' git status (#12266)
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.
2024-05-25 03:41:35 +03:00
|
|
|
env_logger.workspace = true
|
2024-02-27 00:09:22 +03:00
|
|
|
git2.workspace = true
|
|
|
|
|
gpui = {workspace = true, features = ["test-support"]}
|
2024-07-24 01:01:05 +03:00
|
|
|
http_client.workspace = true
|
2024-02-27 00:09:22 +03:00
|
|
|
rand.workspace = true
|
|
|
|
|
settings = {workspace = true, features = ["test-support"]}
|
|
|
|
|
pretty_assertions.workspace = true
|
