Git Bash est extrêmement lent sous Windows 7 x64

Question

J'utilisais Git sous Windows et Ubuntu lors du développement d'un petit projet, faisant souvent des va-et-vient entre les deux. Le problème est que Git Bash devient constamment lent.

Quand je dis lent, je veux dire que l'exécution de cd prend entre 8 et 25 secondes, l'exécution de commandes git entre 5 et 20 secondes et que ls peut prendre jusqu'à 30 secondes parfois. Inutile de dire que ce n'est pas amusant, pour ne pas dire improductif. Je sais que Git est plus lent sous Windows, mais c'est ridicule.

La solution qui a fonctionné - temporairement - pour moi a été de désactiver ma connexion réseau (comme suggéré dans cette réponse ), de démarrer Git Bash, puis de vous reconnecter. Parfois, il continue à fonctionner rapidement pendant des jours, mais les performances finissent toujours par se dégrader. J'ai parcouru pendant des semaines le groupe de discussion msysgit, le débordement de pile, la liste des problèmes de msysgit, etc., mais je n'ai pas été en mesure de proposer des solutions qui fonctionnent.

Jusqu'à présent, j'ai essayé:

• Ajouter des dossiers Git & project à la liste d'exclusion du scanner de virus
• Désactiver complètement mon antivirus (Kaspersky IS 2011)
• S'assurer que Outlook n'est pas en cours d'exécution (Outlook 2007)
• Fermer toutes les autres applications
• Lancer Git Bash en tant qu'administrateur
• Désactivation de la connexion réseau, démarrage de Git Bash et maintien de la connexion désactivée
• Désactivation de la connexion réseau, démarrage de Git Bash, réactivation de la connexion (ne fonctionne que de temps en temps)
• En cours git gc
• Et des combinaisons de ce qui précède

J'ai lu que quelques personnes réussissaient à désactiver le parachèvement de Bash, mais idéalement, j'aimerais le garder actif. La version de msysgit est 1.7.3.1-preview20101002 et le système d'exploitation est Windows 7 x64. Exécuter les mêmes choses sous Linux est, comme on pouvait s'y attendre, extrêmement rapide. J'utiliserais exclusivement Linux, mais je dois aussi exécuter des tâches sous Windows (certaines applications, tests, etc.).

Quelqu'un at-il rencontré un problème similaire? Si oui, quel était le problème sous-jacent et quelle était la solution (le cas échéant)?

Cela va au-delà des référentiels Git, mais juste pour référence, les référentiels avec lesquels j'ai utilisé Git sont plutôt petits: ~ 4-50 fichiers maximum.

Answer 1

Il semble que désinstaller complètement Git, redémarrer (le remède Windows classique) et réinstaller Git était le remède. J'ai également effacé tous les fichiers de configuration bash restants (ils ont été créés manuellement). Tout est rapide à nouveau.

Si, pour une raison quelconque, la réinstallation n’est pas possible (ou souhaitable), j’essaierais certainement de changer la variable PS1 mentionnée dans Réponse de Chris Dolan ; cela a entraîné des accélérations significatives dans certaines opérations.

Answer 2

Vous pouvez considérablement accélérer Git sous Windows en exécutant trois commandes pour définir certaines options de configuration:

git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256

Remarques:

• core.preloadindex effectue des opérations de système de fichiers en parallèle pour masquer la latence (update: activé par défaut dans Git 2.1)

• core.fscache corrige des problèmes de contrôle de compte d'utilisateur, vous n'avez donc pas besoin d'exécuter Git en tant qu'administrateur (update: activé par défaut dans Git pour Windows 2.8)

• gc.auto réduit le nombre de fichiers dans .git /

Answer 3

Avez-vous des informations Git dans votre invite Bash? Si c'est le cas, vous faites peut-être par inadvertance beaucoup trop de travail sur chaque commande. Pour tester cette théorie, essayez le changement temporaire suivant dans Bash:

export PS1='$'

Answer 4

Mon répertoire personnel Windows est sur le réseau et je soupçonnais que les commandes Git Bash y cherchaient en premier. Effectivement, lorsque j'ai examiné $ PATH, il a tout d’abord répertorié/h/bin, où/h est un partage sur un serveur de fichiers Windows, même si/h/bin n’existe pas. J'ai édité/etc/profile et commenté la commande d'exportation qui la met d'abord dans $ PATH:

#export PATH="$HOME/bin:$PATH"

Cela a rendu mes commandes beaucoup plus rapides, probablement parce que Git Bash ne cherchait plus les exécutables sur le réseau. Mon/etc/profile était c:\Program Files (x86)\Git\etc\profile.

Answer 5

J'ai trouvé le lecteur réseau était le problème de performance. HOME indiquait un partage de réseau lent . Je ne pouvais pas remplacer HOMEDRIVE mais ce n’est pas un problème de ce que j’ai vu.

Définissez la variable d’environnement en cliquant avec le bouton droit de la souris sur votre ordinateur sur le bureau -> Propriétés -> Paramètres système avancés -> Variables d’environnement

HOME=%USERPROFILE%

Answer 6

Bien que votre problème puisse être lié au réseau, j’ai personnellement décuplé mes appels git status locaux (de 7 secondes à 700 ms) en faisant deux modifications. Cela se trouve sur un référentiel de 700 Mo avec 21 000 fichiers et un nombre excessif de fichiers binaires volumineux.

L'une consiste à activer les précharges d'index parallèles. A partir d'une invite de commande:

git config core.preloadindex true
Cela a changé time git status de 7 secondes à 2,5 secondes.

Mettre à jour!

Ce qui suit n'est plus nécessaire. Un correctif a corrigé cela depuis mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Cependant, vous devez activer le correctif en tapant
git config core.fscache true

J'ai également désactivé l'UAC et le pilote "luafv" (redémarrage requis). Cela désactive un pilote dans Windows Vista, 7 et 8 qui redirige les programmes essayant d'écrire dans les emplacements système et redirige plutôt ces accès vers un répertoire d'utilisateurs.

Pour voir comment cela affecte les performances de Git, lisez ce qui suit: https://code.google.com/p/msysgit/issues/detail?id=320

Pour désactiver ce pilote, dans regedit, remplacez la clé "start" en HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv par 4 pour désactiver le pilote. Ensuite, définissez le paramètre UAC sur son paramètre le plus bas, "ne jamais notifier".

Si la désactivation de ce pilote vous rend méfiant (cela devrait être le cas), une autre solution est en cours d'exécution sur un lecteur (ou une partition) différent de votre partition système. Apparemment, le pilote ne fonctionne que sur l'accès aux fichiers sur la partition système. J'ai un deuxième disque dur et je vois des résultats identiques lorsqu’il est exécuté avec cette modification du registre sur mon lecteur C comme je le fais sans sur le lecteur D.

Cette modification prend time git status de 2,5 secondes à 0,7 seconde.

Vous pouvez également suivre https://github.com/msysgit/git/pull/94 et https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b vérifier les informations supplémentaires le travail est en cours pour les problèmes de vitesse dans Windows.

Answer 7

Dans le prolongement de la réponse de Chris Dolan, j'ai utilisé le paramètre alternatif PS1 suivant. Ajoutez simplement le fragment de code à votre ~/.profile (sous Windows 7: C: /Users/USERNAME/.profile).

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [\1] / p')"
}

PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

Cela conserve l’avantage d’un Shell coloré et l’affichage du nom de la branche actuelle (s’il se trouve dans un référentiel Git), mais il est nettement plus rapide sur ma machine, de ~ 0,75 s à 0,1 s.

Ceci est basé sur cet article de blog .

Answer 8

J'ai résolu mon problème de Git lent sous Windows 7 x64 en démarrant cmd.exe avec "Exécuter en tant qu'administrateur".

Answer 9

J'ai constaté une amélioration décente en définissant core.preloadindex sur vrai comme recommandé ici .

Answer 10

J'avais le même problème, à la fois dans Git Bash et Git GUI. Les deux programmes fonctionnaient bien, mais ils ont ensuite ralenti au hasard, et je ne pouvais pas comprendre pourquoi.

En fait, c'était Avast. Avast a causé des problèmes à divers programmes (y compris les programmes que j'écris). Je l'ai donc désactivé pendant une seconde. Bash s'exécute désormais aussi rapidement que sous Linux. Je viens d'ajouter le dossier des fichiers du programme Git (C:\Program Files\Git) à la liste d'exclusion Avast, qui s'exécute maintenant aussi rapidement que sous Linux.

Et oui, je me rends compte que le logiciel antivirus n'était pas le problème dans le post original, mais je vais simplement le mettre ici au cas où il serait utile à quelqu'un.

Answer 11

Comme indiqué dans les réponses de Chris Dolan et Wilbert, PS1 vous ralentit.

Plutôt que de désactiver complètement (comme suggéré par Dolan) ou d'utiliser le script proposé par Wilbert, j'utilise une "PS1 stupide" beaucoup plus rapide.

Il utilise (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null:

PS1='\033[33m\]\w \n\[\033[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[\033[00m\]# '

Sur mon Cygwin, cela est plus rapide que la réponse "fast_Git_PS1" de Wilbert - 200 ms contre 400 ms, ce qui réduit donc un peu votre lenteur.

Il n’est pas aussi sophistiqué que __git_ps1 - par exemple, il ne change pas l’invite lorsque vous vous insérez dans le répertoire .git, etc., mais il est suffisant et rapide pour une utilisation quotidienne normale.

_ {Ceci a été testé sur Git 1.7.9 (Cygwin, mais cela devrait fonctionner sur n'importe quelle plate-forme)).} _

Answer 12

Vous pouvez également améliorer considérablement les performances en modifiant la configuration de Git suivante:

git config --global status.submoduleSummary false

Lors de l'exécution de la simple commande git status sous Windows 7 x64, mon ordinateur a pris plus de 30 secondes pour s'exécuter. Une fois cette option définie, la commande est immédiate.

Activer le traçage de Git, comme expliqué dans la page suivante, m'a aidé à trouver l'origine du problème, qui pourrait différer selon votre installation: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git est si lent

Answer 13

Si vous utilisez Git à partir de cmd, essayez de l'exécuter à partir de Git Bash . Dans cmd, git.exe est en fait un wrapper qui configure le bon environnement à chaque démarrage, puis lance le véritable git.exe. Cela peut prendre jusqu'à deux fois plus de temps que nécessaire pour faire ce que vous voulez. Et Git Bash configure l'environnement uniquement au démarrage.

Answer 14

Dans mon cas, c’est en fait un antivirus Avast qui conduit à un ralentissement considérable de Git Bash et même de PowerShell.

J'ai d'abord essayé de désactiver Avast pendant 10 minutes pour voir si cela améliorait la vitesse. Par la suite, j’ai ajouté le répertoire d’installation complet de Git Bash en tant qu’exception dans Avast, en lecture, écriture et exécution. Dans mon cas, c'était C:\Program Files\Git\*.

Answer 15

J'ai rencontré le même problème avec Git pour Windows (msysgit) sous Windows 7 x64 en tant que compte utilisateur limité depuis un certain temps.

D'après ce que j'ai lu ici et dans d'autres endroits, le thème commun semble être le manque de privilèges administratifs et/ou de UAC. Étant donné que le contrôle de compte d'utilisateur est désactivé sur mon système, l'explication selon laquelle il essaie d'écrire/supprimer quelque chose dans le répertoire des fichiers du programme me semble tout à fait logique.

En tout cas, j'ai résolu mon problème en installant la version portable de Git 1.8 avec zipinstaller. Notez que je devais décompresser le fichier de distribution .7z et le remballer sous forme de fichier Zip pour que le zipinstaller fonctionne. J'ai également dû ajouter manuellement ce répertoire à mon chemin système.

La performance est bien maintenant. Même s'il est installé dans le répertoire Program Files (x86), pour lequel je n'ai pas d'autorisations en tant qu'utilisateur limité, il ne semble pas souffrir du même problème.

J'attribue ceci soit au fait que la version portable est un peu plus conservatrice dans laquelle elle écrit/supprime des fichiers, ce qui est probablement le cas, soit à la mise à niveau de 1.7 à 1.8. Je ne vais pas essayer de déterminer laquelle est la raison, il suffit de dire que cela fonctionne beaucoup mieux maintenant, y compris Bash.

Answer 16

Réponses combinées:

1. Wilbert's - Quelles informations inclure dans PS1
2. sinelaw's - (<branch_name>) ou (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-Prompt
# \033 is the same as \e
# 0;32 is the same as 32
CYAN="$(echo -e "\e[1;36m")"
GREEN="$(echo -e "\e[32m")"
YELLOW="$(echo -e "\e[33m")"
RESET="$(echo -e "\e[0m")"

# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}

# you need \] at the end for colors
# Don't set \[ at the beginning or ctrl+up for history will work strangely
PS1='${GREEN}\u@\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

Résultat:

 

Answer 17

En plus de ces autres réponses, j'ai accéléré des projets avec plusieurs sous-modules en utilisant la récupération parallèle de sous-modules (depuis Git 2.8 au début de 2016).

Cela peut être fait avec git fetch --recurse-submodules -j8 et défini avec git config --global submodule.fetchJobs 8, ou le nombre de cœurs que vous avez/voulez utiliser.

Answer 18

Le fait de désactiver AMD Radeon Graphics (ou Intel Graphics) dans le Gestionnaire de périphériques m'a aidé.

 

J'ai trouvé la réponse ici: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

Answer 19

Rien de ce qui précède n'a pu m'aider. Dans mon scénario, le problème se présentait comme ceci:

• Toute commande ll était lente (son exécution prenait environ 3 secondes)
• Toute commande ll ultérieure est exécutée instantanément, mais uniquement si elle se trouve dans les 45 secondes de la commande ls précédente.

Lors du débogage avec Process Monitor , il a été constaté qu’avant chaque commande, il y avait une requête DNS.

Donc, dès que j'ai désactivé mon pare-feu (Comodo dans mon cas) et laissé la commande exécuter le problème est parti. Et il ne revient pas lorsque le pare-feu a été réactivé. Dès que l'occasion se présentera, je mettrai à jour cette réponse avec davantage de détails sur le processus qui exécutait une demande de blocage DNS et sur la cible.

BR, G

Answer 20

Dans mon cas, le raccourci Git Bash était défini sur Start in:%HOMEDRIVE%%HOMEPATH% (vous pouvez le vérifier en cliquant avec le bouton droit de la souris sur Git Bash et en sélectionnant les propriétés). C'était le lecteur réseau. 

La solution consiste à faire pointer sur %HOME%. Si vous ne l'avez pas, vous pouvez le configurer dans les variables d'environnement et maintenant Git Bash devrait être rapide comme l'éclair.

Answer 21

Un de mes collègues avait des problèmes avec Git sous Windows (7) git statuscheckout et add étaient rapides, mais git commit a pris une éternité.

Nous essayons toujours de trouver la cause première de ce problème, mais cloner le référentiel dans un nouveau dossier a résolu son problème.

Answer 22

Comme beaucoup l'ont dit, cela est dû au fait que stash est un script Shell sous Windows, mais depuis Git 2.18.0, le programme d'installation Windows dispose d'une option pour une fonctionnalité expérimentale d'une version intégrée beaucoup plus rapide (~ 90%) de stash - . https://github.com/git-for-windows/build-extra/pull/203 .

Answer 23

J'ai également eu un problème avec la lenteur de git PS1, bien que pendant longtemps, je pensais que c'était un problème de taille de base de données (grand référentiel) et que j'essayais différentes astuces de git gc, et que je cherchais d'autres raisons, tout comme vous. Cependant, dans mon cas, le problème était cette ligne:

function ps1_gitify
{
   status=$(git status 2>/dev/null )      # <--------------------
   if [[ $status =~ "fatal: Not a git repository" ]]
   then
       echo ""
   else
       echo "$(ps1_git_branch_name)  $(ps1_git_get_sha)"
  fi
}

Faire git status pour chaque ligne d'état de la ligne de commande était lent. Aie. C'était quelque chose que j'ai écrit à la main. J'ai vu que c'était un problème quand j'ai essayé le

export PS1='$'

comme mentionné dans une réponse ici. La ligne de commande était rapide comme l'éclair.

Maintenant j'utilise ceci:

function we_are_in_git_work_tree
{
    git rev-parse --is-inside-work-tree &> /dev/null
}

function ps1_gitify
{
    if ! we_are_in_git_work_tree
    then
    ...

À partir de la colonne Post Stack Overflow, avec la branche et les couleurs actuelles de git et tout fonctionne bien. Encore une fois, avoir une ligne de commande rapide Git.