Git & UAC
As a PSA to those using Git in a split-account UAC system (normal non-admin user account & separate admin account).
We were having huge issues with Git processes taking forever - on a machine without this UAC setup a 'git status' would take 0 seconds. On the impacted machines we were seeing averages of 30s.
We figured it was the encryption software, or maybe the antivirus software - nobody could figure it out, and we had the additional red herring of a few machines with corruption issues. Anyways, finally we really started digging into it and discovered that there was one user without any issues on a system that SHOULD have issues. He had this problem at a previous employer - and provided this link:
http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64
Amazing. I applied those changes to two affected machines, closed / reopens the active shells, and BAM. Git was back to normal!
Hopefully this solves some misery for someone else!
I am guessing that there are underlying Git processes that assume UAC is a thing for the current user - when it can't, times out or something and falls back to non-UAC functionality. This makes each call take a lot longer, and so when you have to scan thousands of files, this extra time adds up fast. I had gotten as far as Sysinternals process tracing & xperf IO tracing when we finally got this stroke of luck.
FTA:
We were having huge issues with Git processes taking forever - on a machine without this UAC setup a 'git status' would take 0 seconds. On the impacted machines we were seeing averages of 30s.
We figured it was the encryption software, or maybe the antivirus software - nobody could figure it out, and we had the additional red herring of a few machines with corruption issues. Anyways, finally we really started digging into it and discovered that there was one user without any issues on a system that SHOULD have issues. He had this problem at a previous employer - and provided this link:
http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64
Amazing. I applied those changes to two affected machines, closed / reopens the active shells, and BAM. Git was back to normal!
Hopefully this solves some misery for someone else!
I am guessing that there are underlying Git processes that assume UAC is a thing for the current user - when it can't, times out or something and falls back to non-UAC functionality. This makes each call take a lot longer, and so when you have to scan thousands of files, this extra time adds up fast. I had gotten as far as Sysinternals process tracing & xperf IO tracing when we finally got this stroke of luck.
FTA:
$ git config --global core.preloadindex true
$ git config --global core.fscache true
$ git config --global gc.auto 256
Comments
Post a Comment