Extension causes high cpu load

[joshrbarcodefactory]

waderyan.gitblame-unresponsive.cpuprofile.txt

• Issue Type: Performance
• Extension Name: gitblame
• Extension Version: 10.2.0
• OS Version: Linux x64 5.19.0-45-generic
• VS Code version: 1.77.3

:warning: Make sure to attach this file from your home-directory: :warning:file:///tmp/waderyan.gitblame-unresponsive.cpuprofile.txt

Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

I have been having issues with this extension periodically over the last few months. It gets stuck and displays "Waiting for git blame response" and prevents any other features like format on save feature to work.

It is really a pain when you are using the debugger and this happens because you have to disable the extension, click "Reload", then kill any of the spawned processes from the debugger. I have seen a few reports of this but no one followed the "attach the file" instructions. This is one of the most useful extensions I use, so its a shame to have to turn it off immediately after using it.

Let me know if there is any other info you need from me.

[Sertion]

Hey joshrbarcodefactory! Thank you for reporting the issue and for attaching the cpuprofile.

I see that you are using version 10.2.0 of the extension. In 10.3.0 I added a new feature that limits the number of parallel blame processes that gets spawned. It would be very helpful to know if the issue persist with the new version.

[Sertion]

I have been able to recreate what I think is the issue.

[joshrbarcodefactory]

I couldn't reproduce it when I tried. I will update to 10.3.0 and see if it happens in my everyday use.

[Sertion]

I am no expert on these things but it looks like the issue is that the microtask queue never runs out of things to do.

While the first microtask is parsing the return value from the git blame process stdout stream and sending it to the cache the next git blame chunk is sent and it queues another microtask. As long as there are microtasks in the queue they will keep going and never letting the task queue execute.

This should be quite hard to reproduce as it requires the git blame process to be quite fast (queuing new microtasks when pushing to stdout) while the extension host is slow (parsing and storing git blame information).

I've been testing a few things with different task and microtask interruptions. The latest one is to use setImmediate when processing the git blame process output. That should make the worst case scenario a bit less bad but I do not know if it removes the issue entirely.

I will need do to a bit more digging or if someone with a lot more experience with these things happens upon this can shed some light on it.

[Sertion]

I just uploaded 10.4.0 with a potential fix. I'll close this for now, please comment again if the issue persists!

[alexanderadam]

Version v10.5.0 is still causing high CPU loads for me. Especially when quickly navigating through a file.

How is it working under the hood? Is git blame output loaded once, cached in the background and just updated by line when things changed or is it loading every single line on its own without caching?

[Sertion]

Is git blame output loaded once, cached in the background and just updated by line when things changed or is it loading every single line on its own without caching?

It has a per file cache that gets invalidated whenever the file is closed in the editor and when the file or ./git/HEAD changes.

If the extension is causing high CPU load after the "max two at the time"-change the only reason I can think of is the git blame process itself and I do not have any impact on that.