# project panel: Improve performance in worktrees with lots of files\. \(\#12980\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/eb7b5a7131fc1f693ceff8c314f3d3dae5e6c85c)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: eb7b5a7131fc1f693ceff8c314f3d3dae5e6c85c

Requested commit: eb7b5a7131fc1f693ceff8c314f3d3dae5e6c85c

Commit: eb7b5a7131fc1f693ceff8c314f3d3dae5e6c85c

Tree: 3dc1700fe28075bff98e654c42ea5978fffcf00b

Author: Piotr Osiewicz

Committer: GitHub

## Message

```
project panel: Improve performance in worktrees with lots of files. (#12980)

When working on a repro for a different issue that involved a worktree
with lots of files (100k to be precise), UI became pretty unresponsive.
I pinned it down to us repeatedly preparing a HashSet of all paths in
the currently-scrolled-to worktree, once per each entry in the range
passed to for_each_visible_range (which is e.g. called during
rendering).

This PR makes that hashing happen just once per worktree. Additionally,
we no longer iterate over (potentially) all entries in a given worktree
when calculating the depth of a given entry.

Note that we could probably be smarter about this still; instead of
recalculating the hashset per each call to for_each_visible_entry, we
could do it whenever we update entries in the project panel. However,
with this PR I wanted to get a quick bang for a small buck; I'm pretty
confident in the change as is, it is relatively straightforward and
messing with worktree updates is more involved.



Release Notes:

- Improvement performance of project panel in large worktrees
```

## Parents

- [7798f64d1be9ed5184ff7aa82e1c53299e8ae564](https://git.cafe/gitcafe/zed/commit/7798f64d1be9ed5184ff7aa82e1c53299e8ae564?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/eb7b5a7131fc1f693ceff8c314f3d3dae5e6c85c?format=markdown)