search

Sertion / vscode-gitblame

Visual Studio Code Extension - See Git Blame info in status bar.
https://marketplace.visualstudio.com/items/waderyan.gitblame
MIT License
72 stars 31 forks source link

Spawns many Git processes and uses up CPU #144

Closed thrandale closed 1 year ago

thrandale commented 1 year ago

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

Sertion commented 1 year ago

Hey thrandale! Thanks for the bug report.

Was this when opening and closing multiple files or while navigating a single file?

thrandale commented 1 year ago

Not sure of the exact conditions causing it, but i am consistently opening, closing, and navigating large files.

Sertion commented 1 year ago

What operating system are you using? If you are using Windows do you get the same experience if you use WSL or WSL2?

thrandale commented 1 year ago

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.

stevemandl commented 1 year ago

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. image 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

thrandale commented 1 year ago

@stevemandl I don’t experience the issue with files of that size. When I say large files, I mean 5,000+ lines

Sertion commented 1 year ago

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.

Sertion commented 1 year ago

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.