Spawns many Git processes and uses up CPU
thrandale opened this issue · 8 comments
I recently have experienced where The extension will end up spawning many Git processes (I have seen up to 10), each using 5-15% CPU usage, completely slowing down the computer to an unusable state. I have noticed this mostly when I have one or more large (3000-5000 line) files open. I have had to just disable the extension and stop using it for now because it consistantly makes my computer unusable.
Using v10.2.0
Hey thrandale! Thanks for the bug report.
Was this when opening and closing multiple files or while navigating a single file?
Not sure of the exact conditions causing it, but i am consistently opening, closing, and navigating large files.
What operating system are you using? If you are using Windows do you get the same experience if you use WSL or WSL2?
I am on Windows 11.
If I open in WSL, It appears the same issue exists. If I have the extension disabled my "VmmemWSL" process sits between 10-20% CPU ussage. Though I am unable to track down the git processes, when I enable the exension, the "VmmemWSL" process jumps to 40-50% CPU usage. Tested multiple times with the extension enabled and disabled with the same results.
I am also on Windows 11 with WSL Ubuntu, and I can't reproduce this problem. With or without git blame disabled, I can get the CPU to spike to about 30% while scrolling around in a 400 line file. If anything with git blame enabled the CPU usage was a little less. Both times the CPU settled down when not typing and there was no impact on responsiveness. I tried adjusting the settings: delay 0-500, inline message, status bar, etc... and there was no noticeable change.
The vmmemWSL process never exceeds 1% while using it.
Version: 1.79.2 (user setup)
Commit: 695af097c7bd098fbf017ce3ac85e09bbc5dda06
Date: 2023-06-14T08:57:04.379Z
Electron: 22.5.7
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.22621
@stevemandl I don’t experience the issue with files of that size. When I say large files, I mean 5,000+ lines
I have sort of been able to recreate the issue with my test repository. The issue looks to be that git uses a lot of resources when blaming large files or files in large repositories. The only solution I can see is to add a queue of some sort and limit how many files in parallel the extension is running blames for at the time. This will still not remove the issue; only make it less pronounced.
I have uploaded version 10.3.0 to the marketplace. It has a new setting (gitblame.parallelBlames) that limits the number of parallel blame processes that the extension is running. It defaults to 2 parallel git blame processes.
I will close this for now. If this does not solve the issue I do not know what can be done other than looking into hard drive issues or creating a bug with the git bug tracker.