How to keep git in Visual Studio from consuming constant 35% CPU?

Question

For a while now, I've been seeing the git support of Visual Studio 2013 constantly consuming a large amount of my CPU. I've tried Mark Rendle's methods for disabling git. At one point, removing all the registry keys for git support worked perfectly. However, as of update 2, this method no longer works. I've also tried his extension, but it does not help.

I know that it's related to git because I ran a profiler on Visual Studio, and the results are quite clear.

I get this 30-60 second CPU usage spike anytime I save a file. While editing code, this is quite common. If I have other instances of Visual Studio open at the same time, the other instances also will see a similar CPU spike. So, when having 4 instances of Visual Studio open, I'll see full 100% CPU usage when combining all of the instances. This is extremely annoying and makes Visual Studio borderline unusable at some points

Is there a workaround for this or method to truly disable git support in Visual Studio 2013?

Answer 1

I can't speak to the aforementioned NoGit Extension to disable the git extension, but I've heard good things about it. Still, this is a workaround to your problem, not an actual solution.

Visual Studio hooks up a filesystem listener on your git repository's working directory to identify changes: for example, when you switch branches, we change the branch chooser in Team Explorer. Similarly, when you edit a file, we decorate that file as having changed in Solution Explorer and Team Explorer.

This is generally not an expensive check, however if you have a lot of filesystem churn (like a build!) in places that should be, but are not, in your .gitignore (like build output!) then this is stupidly, crazily expensive.

Please triple-check that your .gitignore file is set up to appropriately ignore your build output. Please make sure that when this is going on that git status does not report your build output or autogenerated files.

If you believe that it is set up correctly, please follow up with me via email and we can try to determine if there's a bug in the ignore matching logic.