Git / Bash est extrêmement lent dans Windows 7 x64

J’ai utilisé Git à la fois sur Windows et Ubuntu pendant le développement d’un petit projet, alternant fréquemment entre les deux. Le problème que j’ai est que Git / Bash devient constamment lent. Quand je dis lent, je veux dire que cd prend de 8 à 25 secondes, que les commandes git durent de 5 à 20 secondes et que cela peut prendre jusqu’à 30 secondes. 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 seule 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, puis de me reconnecter. Parfois, il continue à fonctionner rapidement pendant plusieurs jours, mais les performances finissent toujours par se dégrader. Pendant des semaines, j’ai parcouru le groupe de discussion msysgit, SO, la liste de diffusion msysgit, etc., mais je n’ai pas réussi à trouver des solutions qui fonctionnent.

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

  • Ajout de dossiers git & project à la liste d’exclusion du scanner de virus
  • Désactiver complètement mon scanner de virus (Kaspersky IS 2011)
  • S’assurer que Outlook n’est pas en cours d’exécution (Outlook 2007)
  • Arrêt de toutes les autres applications
  • En cours d’exécution en tant qu’administrateur
  • Désactivation de la connexion réseau, démarrage de git et désactivation de la connexion
  • Désactivation de la connexion réseau, démarrage de git, réactivation de la connexion (fonctionne occasionnellement)
  • Running git gc
  • Et des combinaisons de ce qui précède

J’ai lu que deux personnes avaient réussi à désactiver Bash mais j’aimerais idéalement que cela rest actif. La version de msysgit est 1.7.3.1-preview20101002 et le système d’exploitation est Windows 7 x64. Faire fonctionner les mêmes choses sous Linux est, comme on pouvait s’y attendre, extrêmement rapide. J’utiliserais exclusivement Linux, mais je dois aussi faire tourner des choses 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)?

Edit: Cela va au-delà des seuls repositorys git, mais juste à titre de référence, les repos que j’ai utilisés avec git with ont été assez petits: ~ 4 à 50 fichiers maximum.

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 fait des opérations de système de fichiers en parallèle pour cacher la latence (mise à jour: activée par défaut dans git 2.1)

  • core.fscache corrige les problèmes UAC, vous n’avez donc pas besoin de lancer git en tant qu’administrateur (update: activé par défaut dans Git pour Windows 2.8)

  • gc.auto minimise le nombre de fichiers en .git /

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

 export PS1='$' 

Mon répertoire de base Windows se trouve sur le réseau et je soupçonnais que les commandes de Git Bash regardaient en premier lieu. Bien sûr, quand j’ai regardé $ PATH, il y avait d’abord / 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 place en premier dans $ PATH:

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

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

J’ai trouvé le lecteur réseau était le problème de performance. HOME indiquait un partage réseau lent. Je n’ai pas pu annuler 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 sur votre ordinateur sur le bureau -> propriétés -> Paramètres système avancés -> Variables d’environnement Ajouter à la section Variables utilisateur

 HOME=%USERPROFILE% 

Bien que votre problème puisse être basé sur le réseau, j’ai personnellement accéléré mes appels d’ git status local (7 secondes à 700 ms) en effectuant deux modifications. Ceci est sur un repository de 700 Mo avec 21 000 fichiers et un nombre excessif de gros fichiers binarys.

L’une permet d’activer les préchargements d’index parallèles. À partir d’une invite de commande:
git config core.preloadindex true
Cela a changé le time git status de 7 secondes à 2,5 secondes.

Mettre à jour!

Ce qui suit n’est plus nécessaire. Un patch 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 requirejs). Cela désactive un pilote dans Windows Vista, 7 et 8 qui redirige les programmes essayant d’écrire sur les emplacements du système et redirige ces access vers un répertoire utilisateur.

Pour voir comment ces effets affectent les effets, lisez ici: https://code.google.com/p/msysgit/issues/detail?id=320

Pour désactiver ce pilote, dans regedit, remplacez la clé “start” de HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv par 4 pour désactiver le pilote. Ensuite, mettez UAC à son réglage le plus bas, “Never not”.

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

Ce changement prend du time git status passer 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 pour vérifier le travail supplémentaire en cours pour les problèmes de vitesse dans Windows. .

Dans le prolongement de la réponse de Chris Dolan, j’ai utilisé le paramètre PS1 suivant. Ajoutez simplement le fragment de code à votre fichier ~ / .profile (sous Win7: 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’une shell colorée et l’affichage du nom de la twig actuelle (si dans un repository git), mais est nettement plus rapide sur ma machine, de ~ 0,75s à 0,1s.

Basé sur ce blog .

Il semble que la désinstallation complète de Git, le redémarrage (le remède classique à Windows) et la réinstallation de Git étaient la solution. J’ai également effacé tous les fichiers de configuration bash restants (ils ont été créés manuellement). Tout est à nouveau rapide.

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

J’ai résolu mon problème de git lent sur Win 7 x64 en démarrant cmd.exe avec “Exécuter en tant qu’administrateur”.

J’ai vu une amélioration décente en définissant core.preloadindex sur true, comme recommandé ici .

Je sais que c’est vieux, mais j’avais le même problème, à la fois chez Git Bash et chez Git Gui. Les deux programmes fonctionnent bien, mais ils ont été ralentis au hasard et je ne pouvais pas comprendre pourquoi. En fait, c’était Avast. Avast a causé des choses étranges à divers programmes (y compris les programmes que j’écris), donc je l’ai désactivé pendant une seconde, et bien sûr, Bash fonctionne maintenant aussi vite que sous Linux. Je viens d’append le dossier des fichiers du programme Git (C: \ Program Files \ Git) à la liste d’exclusion Avast, et maintenant il s’exécute aussi vite que sous Linux.

Et oui, je me rends compte que l’Antivirus n’était pas le problème dans le message original, mais je vais juste mettre ceci ici au cas où cela serait utile à quelqu’un.

Comme noté 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 un “dumb PS1” qui est 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, c’est plus rapide que la réponse “fast_git_ps1” de Wilbert – 200ms contre 400ms, ce qui réduit un peu votre lenteur.

Il n’est pas aussi sophistiqué que __git_ps1 – par exemple, il ne modifie pas l’invite lorsque vous cd dans le répertoire .git, etc. mais pour un usage quotidien normal, c’est assez bon et rapide.

Testé sur git 1.7.9 (cygwin, mais devrait fonctionner sur n’importe quelle plate-forme)

Vous pouvez également obtenir un gain de performance très régulier en modifiant la configuration git suivante:

 git config --global status.submoduleSummary false 

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

Activer le propre suivi de Git comme expliqué dans la page suivante m’a aidé à trouver l’origine du problème, qui peut être différent dans votre installation: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- lent

Réponses combinées:

  1. Wilbert’s – quelles informations inclure dans PS1
  2. sinelaw’s – () ou ()
 # 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:

frolowr @ RWAMW36650 / c / projets / elm-math-kids (maître) $

J’ai rencontré le même problème en exécutant git pour Windows (msysgit) sur Windows 7 x64 en tant que compte utilisateur limité pendant un certain temps. D’après ce que j’ai lu ici et ailleurs, le thème commun semble être le manque de privilèges administratifs et / ou de l’UAC. L’UAC étant désactivé sur mon système, l’explication qu’il tente d’écrire / supprimer quelque chose dans le répertoire des fichiers de programme me semble la plus logique.

En tout cas, j’ai résolu mon problème en installant la version portable de git 1.8 avec zipinstaller. Notez que j’ai dû décompresser le fichier de dissortingbution .7z et le réemballer en tant que fichier zip pour que zipinstaller fonctionne. J’ai également dû append manuellement ce répertoire à mon chemin système.

La performance va bien maintenant. Bien qu’il soit installé dans le répertoire Program Files (x86), pour lequel je ne dispose pas des permissions en tant qu’utilisateur limité, il ne semble pas rencontrer le même problème. J’atsortingbue ceci soit au fait que la version portable est un peu plus conservasortingce en ce qui concerne l’écriture / la suppression de fichiers, ce qui est probablement le cas, ou la mise à niveau de 1.7 à 1.8. Je ne vais pas essayer de déterminer lequel est la raison, il suffit de dire que cela fonctionne beaucoup mieux maintenant, y compris bash.

Dans mon cas, il s’agissait en fait d’un antivirus Avast menant à git bash et même Powershell devenant vraiment lent.

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 de Git Bash en tant qu’exception dans Avast, pour Read, Write et Execute. Dans mon cas c’était C:\Program Files\Git\* .

Si vous utilisez Git à partir de cmd, essayez de l’exécuter depuis Git Bash. Dans cmd, git.exe est en fait un wrapper qui configure l’environnement correct chaque fois que vous le lancez, puis lance uniquement le fichier git.exe réel. Cela peut prendre deux fois plus de temps que nécessaire pour faire ce que vous voulez. Et Git Bash ne configure l’environnement que lorsqu’il démarre.

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 (environ 3 secondes à exécuter)
  • Toute autre commande subséquente a été exécutée instantanément, mais seulement dans les 45 secondes suivant la commande ls précédente .

En ce qui concerne le 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 que la commande est exécutée, le problème est résolu. Et il ne revient pas lorsque le pare-feu a été réactivé. Avec la première opportunité, je mettrai à jour cette réponse avec plus de détails sur le processus faisant une requête DNS bloquante et sur la cible.

BR, G

Seule la désactivation de AMD Radeon Graphics (ou Intel Graphics) dans le Gestionnaire de périphériques m’a aidé.

entrer la description de l'image ici

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

En plus de ces autres réponses, j’ai accéléré les projets avec plusieurs sous-modules en utilisant la récupération de sous-modules parallèles (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.

J’avais aussi un problème avec la lenteur de git PS1, bien que pendant longtemps je pensais que c’était un problème de taille de db (big repo), et essayait divers git gc sortingks, et cherchais d’autres raisons, 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 } 

Donc, ce qui était lent faisait le statut git pour chaque ligne d'état de la ligne de commande. 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 très rapide.

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 ce https://stackoverflow.com/a/11975827/2492808 et cela fonctionne bien. Encore une fois, avoir la ligne de commande rapide git.

Dans mon cas, le raccourci git bash a été 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 à indiquer %HOME% . Si vous ne l’avez pas, vous pouvez le configurer dans les variables d’environnement et maintenant git bash devrait être rapide.

Je suis vraiment en retard à la fête, je sais …

… mais: un de mes collègues a eu des problèmes avec git on windows (7) git status checkout et add ont été rapides, mais git commit pris des années.

Nous essayons toujours de trouver la cause profonde de cela, mais le clonage du repository dans un nouveau dossier a résolu son problème. Je pensais que je l’appendais ici, au cas où quelqu’un d’autre aurait le même problème et cherchait toujours une solution.