Closed shodanium closed 3 years ago
GIT_TRACE output exists, but is is less than useful
Probably GIT_TRACE_PERFORMANCE
will be more helpful.
On a hunch, I would say that maybe git -P diff
would be faster? If so, then you are probably observing the startup cost of the MSYS2 runtime that is a consequence of the pager (less.exe
) being an MSYS2 program.
Nope, private work repo. Seeing this issue with different repos though.
As a rule of thumb, if your work repository is private, don't even mention it, but try to reproduce the problem in a minimal (or toy) repository.
For example, if you see the same issue in a repository that you just created via
git init test-dir
cd test-dir
echo Hello >world.txt
git add world.txt
git commit -m initial
echo world >world.txt
git diff
then it would be a good idea to mention that.
Also, all my attempts to post to mailing list failed for some reason.
Probably your mailer insists on adding an HTML part, which the Git mailing list flatly rejects.
Probably GIT_TRACE_PERFORMANCE will be more helpful.
On a hunch, I would say that maybe git -P diff would be faster?
Thank you. I will try all that the next time the issue manifests. In the meantime, got back from traveling, and back to a somewhat better Internet connection(s) => and suddenly, the issue seems to be gone! At least, it did not manifest in the last several days. Also, I think it did not happen while working on the flight, with network off.
So on a counter-hunch, this looks veeery much like running "git diff" does, rather unexpectedly to my taste, some (shady) network-related requests. Which are only occasionally slow on my "regular" connections (I occasionally see this problem on "regular" connections too), but were always very slow while traveling, but were getting cached for a very small while.
Any pointers as to how I can debug those the next time? :)
Re repos, also duly noted, and next time I will try other repos. I strongly suspect that using pretty much any repo would trigger the problem, just did not have enough time (and bandwidth!) to fiddle more, clone a moderately big one, and/or create a trivial one.
Oh, there and was another bit that I just remembered. Just in case, maybe this could help to narrow it down.
"git status" either did not have the issue at all, or very very rarely.
"git diff" and "git log" had. Even immediately after a quick enough "git status" they would be slow.
Network activity from MSYS in some cases, perchance?
Any pointers as to how I can debug those the next time? :)
Yes. The culprit is most likely in the startup of the MSYS2 runtime (which less.exe
uses to emulate a POSIX system). I also got the hunch that the MSYS2 runtime tries to contact the domain controller upon startup, for some information that we actually do not need at all...
"git status" either did not have the issue at all, or very very rarely.
git status
does not run the pager. Hence no MSYS2 runtime involved.
The issue manifested a couple times again today, and git -P seemed to help.
Pinging the domain controller is definitely very possible as all the manifestations only seem to happen when I'm on a VPN connection to work.
Anything that can be done about MSYS2 startup in this particular case? :)
Wanted to bump this issue. Our office is experiencing the same intermittent slowdowns with git diff. Any thoughts on a workaround?
@jordanbrowneb I'm not sure anyone is working on this.
Can you give more details of your setup and testing? Can you make the issue repeatable? do all PCs suffer, or just some?
What is the same/different about those that suffer from those that don't? VPNs and Proxies?
Do you have timing statistics, does it depend on the file that is being diff'd. Have all the machines been 'g'cd, and repacked?
Has any network sniffing been done to see if there are indications there?
Better clues are needed from those that are at the scene of the crime ;-)
@shodanium - any news from your systems?
Yes, git -P helps.
It could be potentially helpful to have a ProcMon dump of such a slow run.
Closing this as stale.
Setup
The environment is IMO rather bland. The issue is not related to antivirus (Windows Defender etc are all disabled).
Details
cmd.exe and FAR, same situation in both cases
I expect a diff in less than 1 second (less than 0.1 second actually).
I get a diff but in 15-20 seconds. Immediately running "git diff" again would actually complete in 0.1 seconds or less. However, after a trivial amount of work in a different window (say, edit a source file a little and save it), git diff would be insanely slow again.
Neither CPU nor disk activity is reported by Task Manager during that slowdown. 0-1% CPU usage, 0-1% disk activity. I would assume that "git diff" does NOT do any network activity, huh.
GIT_TRACE output exists, but is is less than useful: Z:\work...\generator>timeit git diff 15:18:56.996500 exec-cmd.c:236 trace: resolved executable dir: C:/Bin/Git/mingw64/bin 15:18:56.997001 git.c:419 trace: built-in: git diff 15:18:56.999006 run-command.c:643 trace: run_command: unset GIT_PAGER_IN_USE; LESS=FRX LV=-c less command took 0:0:15.51 (15.51s total)
ProcMon output indicates that git manages to scan the FS real quick, and then just sits doing nothing (waiting for 4 threads, that in turn are sitting doing nothing, to complete???) for about 15 seconds. The following is from ProcMon and the last column is TID:
Nope, private work repo. Seeing this issue with different repos though.
Also, all my attempts to post to mailing list failed for some reason.