You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
I've noticed directories ignored in .gitignore still significantly impact performance. #1776
I check out various GIT work trees in a sub folder that's ignored via the .gitignore file. I'm using 1.2.2 released recently, with the new .gitignore processing.
The results in performance are pretty staggering:
It does actually ignore them for formatting, but clearly the performance hit is big.
I'd be happy to experiment with this and attempt a pull request if you have any pointers to where I should look?
I can take a look at this, I am pretty sure I know what the problem is.
The latest implementation of gitignore uses a port of 3rd nuget library and there was some code that recursively looks at parent directories. I am pretty sure that is the problem. It didn't show up in my testing, but with 15 work trees I imagine there are a lot of extra files/folders in .git.
I was already thinking of trying to modify this code to work more like the 2nd nuget library, which depends almost entirely on regex.
@belav got it - fwiw it was also there on 1.2.1, I had seen your commit with a gitignore change coming so thought I'd wait to test that before filing the issue. In case it helps/adds context, the extra files are actually in a non-git folder; the worktree is checked out in .random folder in the root of the repo, which is ignored.
Ah good to know. I came up with a plan that didn't involve reworking gitignore again which I think will still work with just a bit of tweaking. I have a good way to test that my csharpier implementation is matching how git functions.
Looks like my idea worked pretty well. I think there is still some improvement that could be made to the gitignore logic, but this really speeds things up. Here is 5 work trees before and after the linked PR
And adding another 5 worktrees (for 10 total) is 95.470s vs 22.474s. It will slow down a bit as more worktrees are added but not anywhere close to before this change.
Activity
belav commentedon Dec 14, 2025
I can take a look at this, I am pretty sure I know what the problem is.
The latest implementation of gitignore uses a port of 3rd nuget library and there was some code that recursively looks at parent directories. I am pretty sure that is the problem. It didn't show up in my testing, but with 15 work trees I imagine there are a lot of extra files/folders in .git.
I was already thinking of trying to modify this code to work more like the 2nd nuget library, which depends almost entirely on regex.
janpieterz commentedon Dec 14, 2025
@belav got it - fwiw it was also there on 1.2.1, I had seen your commit with a gitignore change coming so thought I'd wait to test that before filing the issue. In case it helps/adds context, the extra files are actually in a non-git folder; the worktree is checked out in
.randomfolder in the root of the repo, which is ignored.belav commentedon Dec 14, 2025
Ah good to know. I came up with a plan that didn't involve reworking gitignore again which I think will still work with just a bit of tweaking. I have a good way to test that my csharpier implementation is matching how git functions.
More efficient way of finding files that may need to be formatted
belav commentedon Dec 14, 2025
Looks like my idea worked pretty well. I think there is still some improvement that could be made to the gitignore logic, but this really speeds things up. Here is 5 work trees before and after the linked PR
belav commentedon Dec 14, 2025
And adding another 5 worktrees (for 10 total) is 95.470s vs 22.474s. It will slow down a bit as more worktrees are added but not anywhere close to before this change.
belav commentedon Dec 14, 2025
1.2.3 is available now if you want to confirm it improves things for you
More efficient way of finding files that may need to be formatted (be…
janpieterz commentedon Dec 16, 2025
@belav dropped from ~40 seconds to ~10 seconds, awesome! Removing all work trees results in ~3 seconds, but considerable improvement. Thanks a lot.
perf: cache `IgnoreWithBasePath` (#1758)
perf: cache `IgnoreWithBasePath` (#1758)
perf: cache `IgnoreWithBasePath` (#1758)
perf: cache `IgnoreWithBasePath` (#1758)
perf: cache `IgnoreWithBasePath` (#1758)