2

I am using git bash on Windows 7 which is extremely slow. The user profile is on a network drive, so I changed the start to start on the c: drive. I also removed the PS1 prompt and I just use $.

I also have done:

$ git config --global core.preloadindex true
$ git config --global core.fscache true

Some things have speed up, but the git commands themselves are extremely slow. Any idea why? Here is a strace. 

$ GIT_TRACE=1 git stash
09:27:27.099458 git.c:594               trace: exec: 'git-stash'
09:27:27.099458 run-command.c:369       trace: run_command: 'git-stash'
09:27:28.862258 git.c:594               trace: exec: 'git-sh-i18n--envsubst' '--variables' 'usage: $dashless $USAGE'
09:27:28.862258 run-command.c:369       trace: run_command: 'git-sh-i18n--envsubst' '--variables' 'usage: $dashless $USAGE'
09:27:29.096258 git.c:594               trace: exec: 'git-sh-i18n--envsubst' 'usage: $dashless $USAGE'
09:27:29.096258 run-command.c:369       trace: run_command: 'git-sh-i18n--envsubst' 'usage: $dashless $USAGE'
09:27:29.877258 git.c:369               trace: built-in: git 'rev-parse' '--git-dir'
09:27:30.267258 git.c:369               trace: built-in: git 'rev-parse' '--git-path' 'objects'
09:27:30.766458 git.c:369               trace: built-in: git 'rev-parse' '--show-toplevel'
09:27:30.984858 git.c:369               trace: built-in: git 'rev-parse' '--git-path' 'index'
09:27:31.281258 git.c:369               trace: built-in: git 'config' '--get-colorbool' 'color.interactive'
09:27:31.608858 git.c:369               trace: built-in: git 'config' '--get-color' 'color.interactive.help' 'red bold'
09:27:31.967658 git.c:369               trace: built-in: git 'config' '--get-color' '' 'reset'
09:27:32.375258 git.c:369               trace: built-in: git 'ls-files' '--error-unmatch' '--'
09:27:32.702858 git.c:369               trace: built-in: git 'update-index' '-q' '--refresh'
09:27:33.048058 git.c:369               trace: built-in: git 'diff-index' '--quiet' '--cached' 'HEAD' '--ignore-submodules' '--'
09:27:33.392258 git.c:369               trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' '--'
No local changes to save

On Cygwin, real time is only 3 seconds. Here on git bash, 9 seconds. 

$ time git stash
No local changes to save

real    0m9.172s
user    0m0.015s
sys     0m0.108s
$

Here is Cygwins trace to compare against:

$  GIT_TRACE=1 git stash
13:02:51.567376 git.c:595               trace: exec: 'git-stash'
13:02:51.567376 run-command.c:369       trace: run_command: 'git-stash'
13:02:52.740271 git.c:595               trace: exec: 'git-sh-i18n--envsubst' '--variables' 'usage: $dashless $USAGE'
13:02:52.740271 run-command.c:369       trace: run_command: 'git-sh-i18n--envsubst' '--variables' 'usage: $dashless $USAGE'
13:02:52.990489 git.c:595               trace: exec: 'git-sh-i18n--envsubst' 'usage: $dashless $USAGE'
13:02:52.990489 run-command.c:369       trace: run_command: 'git-sh-i18n--envsubst' 'usage: $dashless $USAGE'
13:02:53.459647 git.c:371               trace: built-in: git 'rev-parse' '--git-dir'
13:02:53.694226 git.c:371               trace: built-in: git 'rev-parse' '--git-path' 'objects'
13:02:53.975720 git.c:371               trace: built-in: git 'rev-parse' '--show-toplevel'
13:02:54.085191 git.c:371               trace: built-in: git 'rev-parse' '--git-path' 'index'
13:02:54.194661 git.c:371               trace: built-in: git 'config' '--get-colorbool' 'color.interactive'
13:02:54.304131 git.c:371               trace: built-in: git 'config' '--get-color' 'color.interactive.help' 'red bold'
13:02:54.413601 git.c:371               trace: built-in: git 'config' '--get-color' '' 'reset'
13:02:54.523071 git.c:371               trace: built-in: git 'update-index' '-q' '--refresh'
13:02:54.775294 git.c:371               trace: built-in: git 'diff-index' '--quiet' '--cached' 'HEAD' '--ignore-submodules' '--'
13:02:54.900403 git.c:371               trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'
No local changes to save
dman
  • 10,406
  • 18
  • 102
  • 201
  • 2
    Call me a cynic but perhaps it's because the Linux sub system was developed by Microsoft. – Raman Sailopal Jul 11 '17 at 15:22
  • What's "strace" doing in the title? If you had a syscall-level trace of what was going on, you'd probably know exactly where it was slow. This is **much** higher-level, and comparatively useless as a result. – Charles Duffy Jul 11 '17 at 16:24
  • ...beyond that, I'm not really sure that this is on-topic just from a breadth/scope perspective. This is a topic on which I could easily see someone doing a few weeks of investigation, and for which there would be a new and different answer as soon as the most immediate bottlenecks are removed, as opposed to a question with a clean and canonical answer. – Charles Duffy Jul 11 '17 at 16:25
  • (I'd strongly suggest validating that your network store isn't actually being hit during these operations, btw -- perhaps you might pull out wireshark for the purpose). – Charles Duffy Jul 11 '17 at 16:27
  • The strace is recommended from Git For Windows https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues to diagnose performance issues. – dman Jul 11 '17 at 16:30
  • 1
    That's not strace. That's git's internal trace, a different beast entirely. – jthill Jul 11 '17 at 17:01
  • @RamanSailopal Did Microsoft create the bash client that comes with git? That's news to me. – Lasse V. Karlsen Jul 11 '17 at 17:21
  • 1
    Are you running 32-bit or 64-bit git/bash? – Lasse V. Karlsen Jul 11 '17 at 17:22
  • 1
    What does the equivalent trace look like for Cygwin? The network drive immediately draws my attention, it's a variable you cannot control. Can you remove it from the testing? – Schwern Jul 11 '17 at 17:22
  • @LasseV.Karlsen `"C:\Program Files (x86)\Git\git-bash.exe"` and `git version 2.13.0.windows.1` – dman Jul 11 '17 at 18:08

1 Answers1

0

First, regarding strace, you now have a new option with Git 2.27 (Q2 2020)

See commit 3efc128 (09 Apr 2020), and commit b6852e1 (08 Apr 2020) by Johannes Schindelin (dscho).
See commit a748f3f (08 Apr 2020) by Matthias Aßhauer (rimrul).
(Merged by Junio C Hamano -- gitster -- in commit b3eb70e, 22 Apr 2020)

mingw: help debugging by optionally executing bash with strace

Signed-off-by: Johannes Schindelin

MSYS2's strace facility is very useful for debugging... With this patch, the bash will be executed through strace if the environment variable GIT_STRACE_COMMANDS is set, which comes in real handy when investigating issues in the test suite.

Also support passing a path to a log file via GIT_STRACE_COMMANDS to force Git to call strace.exe with the -o <path> argument, i.e. to log into a file rather than print the log directly.

That comes in handy when the output would otherwise misinterpreted by a calling process as part of Git's output.

Note: the values "1", "yes" or "true" are not specifying paths, but tell Git to let strace.exe log directly to the console.

Second, don't forget recent Git version (2.22+) the trace2 utility

In your case, set GIT_TRACE2_PERFORMANCE=1&& git <command> would help see where the performance issue occurs

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250