it-swarm.com.de

Git Bash ist unter Windows 7 x64 extrem langsam

Ich habe Git sowohl unter Windows als auch unter Ubuntu während der Entwicklung eines kleinen Projekts verwendet und häufig zwischen den beiden hin und her gewechselt. Das Problem ist, dass Git Bash immer langsamer wird.

Wenn ich langsam sage, meine ich, dass das Ausführen von cd zwischen 8 und 25 Sekunden dauert, das Ausführen von git-Befehlen 5-20 Sekunden dauert und ls manchmal bis zu 30 Sekunden dauern kann. Es ist unnötig zu sagen, dass dies keinen Spaß macht, ganz zu schweigen von unproduktiv. Ich weiß, dass Git unter Windows langsamer ist, aber das ist lächerlich.

Die eine Lösung, die vorübergehend funktioniert hat, bestand für mich darin, meine Netzwerkverbindung zu deaktivieren (wie in diese Antwort vorgeschlagen), Git Bash zu starten und dann die Verbindung wieder herzustellen. Manchmal läuft es noch Tage danach schnell, aber die Leistung nimmt mit der Zeit immer ab. Ich habe die msysgit-Diskussionsgruppe, den Stack Overflow, die Liste der msysgit-Ausgaben usw. seit Wochen ein- und ausgeschaltet, aber ich konnte keine Lösungen finden, die funktionieren.

Bisher habe ich versucht:

  • Hinzufügen von Git & Projektordnern zur Ausschlussliste des Virenscanners
  • Vollständige Deaktivierung meines Virenscanners (Kaspersky IS 2011)
  • Sicherstellen, dass Outlook nicht ausgeführt wird (Outlook 2007)
  • Alle anderen Anwendungen herunterfahren
  • Git Bash als Administrator ausführen
  • Deaktivieren der Netzwerkverbindung, Starten von Git Bash und Deaktivieren der Verbindung
  • Netzwerkverbindung deaktivieren, Git Bash starten, Verbindung wieder aktivieren (funktioniert nur gelegentlich)
  • git gc ausführen
  • Und Kombinationen davon

Ich habe gelesen, dass es einigen Leuten gelungen ist, die Bash-Vollendung zu deaktivieren, aber im Idealfall würde ich das gerne aktiv halten. Die Version von msysgit ist 1.7.3.1-preview20101002 und das Betriebssystem ist Windows 7 x64. Das Ausführen der gleichen Dinge unter Linux ist vorhersagbar blitzschnell. Ich würde ausschließlich Linux verwenden, aber ich muss auch unter Windows laufen (bestimmte Anwendungen, Tests usw.).

Hat jemand ein ähnliches Problem festgestellt? Wenn ja, was war das zugrunde liegende Problem und was war die Lösung (falls vorhanden)?

Dies geht über die Git-Repositorys hinaus, aber nur zur Referenz: Die Repositorys, die ich mit Git verwende, waren ziemlich klein: ~ 4-50 Dateien maximal.

384
Gemini14

Es scheint, dass die vollständige Deinstallation von Git, der Neustart (die klassische Windows-Heilung) und die Neuinstallation von Git die Heilung war. Ich habe auch alle bash-Konfigurationsdateien gelöscht, die übrig waren (sie wurden manuell erstellt). Alles ist wieder schnell.

Wenn eine Neuinstallation aus irgendeinem Grund nicht möglich (oder wünschenswert) ist, würde ich auf jeden Fall versuchen, die PS1-Variable zu ändern, auf die in Chris Dolans Antwort ; Dies führte bei bestimmten Vorgängen zu erheblichen Beschleunigungen.

15
Gemini14

Sie können Git unter Windows erheblich beschleunigen, indem Sie drei Befehle ausführen, um einige Konfigurationsoptionen festzulegen:

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

Anmerkungen:

  • core.preloadindex führt Dateisystemvorgänge parallel aus, um die Latenzzeit auszublenden (Update: in Git 2.1 standardmäßig aktiviert).

  • core.fscache behebt Probleme mit der Benutzerkontensteuerung, sodass Sie Git nicht als Administrator ausführen müssen (Update: standardmäßig in Git für Windows 2.8 aktiviert).

  • gc.auto minimiert die Anzahl der Dateien in .git /

384
shoelzer

Haben Sie Git-Informationen in Ihrer Bash-Eingabeaufforderung? Wenn ja, arbeiten Sie vielleicht mit jedem Befehl zu viel Arbeit. Um diese Theorie zu testen, versuchen Sie die folgende temporäre Änderung in Bash:

export PS1='$'
85
Chris Dolan

Mein Windows-Home-Verzeichnis befindet sich im Netzwerk und ich hatte den Verdacht, dass Git Bash-Befehle zuerst dort gesucht wurden. Wenn ich mir $ PATH ansah, wurde es/h/bin zuerst aufgeführt, wobei/h eine Freigabe auf einem Windows-Dateiserver ist, obwohl/h/bin nicht existiert. Ich habe/etc/profile bearbeitet und den Exportbefehl auskommentiert, der ihn an erster Stelle in $ PATH setzt:

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

Dadurch liefen meine Befehle viel schneller, wahrscheinlich, weil Git Bash nicht mehr über das Netzwerk nach den ausführbaren Dateien sucht. Mein/etc/profile war c:\Programme (x86)\Git\etc\profile.

72
Rob Johnson

Ich fand das Netzlaufwerk war das Leistungsproblem. HOME wies auf eine langsame Netzwerkfreigabe hin .. HOMEDRIVE konnte nicht überschrieben werden, aber das ist aus meiner Sicht kein Problem.

Legen Sie die Umgebungsvariable fest, indem Sie mit der rechten Maustaste auf den Desktop Ihres Computers klicken -> Eigenschaften -> Erweiterte Systemeinstellungen -> Umgebungsvariablen Hinzufügen zu den Benutzervariablen

HOME=%USERPROFILE%
32
MichaelK

Während Ihr Problem möglicherweise netzwerkbasiert ist, habe ich meine lokalen git status-Anrufe durch zwei Änderungen um das 10-fache beschleunigt (mindestens 7 Sekunden auf 700 ms). Dies ist ein 700-MB-Repository mit 21.000 Dateien und einer zu großen Anzahl großer Binärdateien.

Eine aktiviert parallele Indexvorladungen. Von einer Eingabeaufforderung aus:

git config core.preloadindex true
Dies änderte sich time git status von 7 Sekunden auf 2,5 Sekunden.

Aktualisieren!

Folgendes ist nicht mehr nötig. Ein Patch hat dies seit mysysgit 1.9.4 behoben
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Sie müssen den Fix jedoch durch Eingabe aktivieren
git config core.fscache true

Ich habe auch die Benutzerkontensteuerung und den "luafv" -Treiber deaktiviert (Neustart erforderlich). Dadurch wird ein Treiber in Windows Vista 7 und 8 deaktiviert, der Programme umleitet, die versuchen, an Systemspeicherorte zu schreiben, und diese Zugriffe stattdessen auf ein Benutzerverzeichnis umleiten.

Informationen dazu, wie sich dies auf die Git-Leistung auswirkt, finden Sie hier: https://code.google.com/p/msysgit/issues/detail?id=320

Um diesen Treiber zu deaktivieren, ändern Sie in regedit den Schlüssel "Start" unter HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv in 4, um den Treiber zu deaktivieren. Setzen Sie dann UAC auf die niedrigste Einstellung, "niemals benachrichtigen".

Wenn Sie durch das Deaktivieren dieses Treibers vorsichtig werden (sollte es), wird eine Alternative auf einem anderen Laufwerk (oder einer Partition) ausgeführt als Ihrer Systempartition. Anscheinend läuft der Treiber nur mit Dateizugriff auf der Systempartition. Ich habe eine zweite Festplatte und sehe identische Ergebnisse, wenn ich mit dieser Registrierungsänderung auf meinem Laufwerk C laufe, wie auf dem Laufwerk D ohne.

Diese Änderung dauert time git status von 2,5 Sekunden auf 0,7 Sekunden.

Möglicherweise möchten Sie auch https://github.com/msysgit/git/pull/94 und https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b folgen Für Geschwindigkeitsprobleme in Windows wird gearbeitet.

22
Jeff Lamb

In einer Erweiterung zu Chris Dolans Antwort habe ich die folgende alternative PS1-Einstellung verwendet. Fügen Sie einfach das Codefragment zu Ihrem ~/.profile hinzu (unter 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\]\[email protected]\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

Dies hat den Vorteil einer farbigen Shell und der Anzeige des aktuellen Zweignamens (wenn in einem Git-Repository), ist jedoch auf meinem Computer deutlich schneller, von ~ 0,75 s bis 0,1 s.

Dies basiert auf diesem Blogbeitrag .

21
Wilbert

Ich habe mein langsames Git-Problem unter Windows 7 x64 gelöst, indem ich cmd.exe mit "Als Administrator ausführen" gestartet habe.

10

Ich habe eine anständige Verbesserung gesehen, indem ich core.preloadindex auf true gesetzt habe, wie hier empfohlen .

8
Andy

Ich hatte das gleiche Problem, sowohl in Git Bash als auch in Git GUI. Beide Programme liefen zwar gut, ließen sich jedoch nach dem Zufallsprinzip verlangsamen und ich konnte nicht verstehen, warum.

Wie sich herausstellte, war es Avast. Avast hat dazu geführt, dass bei verschiedenen Programmen (einschließlich von Programmen, die ich schreibe) seltsame Dinge passieren. Ich habe es für eine Sekunde deaktiviert, und Bash läuft jetzt genauso schnell wie unter Linux. Ich habe gerade den Git-Programmdateienordner (C:\Program Files\Git) zur Avast-Ausschlussliste hinzugefügt, und jetzt läuft er genauso schnell wie unter Linux.

Und ja, ich weiß, dass die Antivirensoftware nicht das Problem des ursprünglichen Beitrags war, aber ich werde dies hier nur für den Fall angeben, dass es für jemanden nützlich ist.

5
Nkosi Dean

Wie in den Antworten von Chris Dolan und Wilbert festgestellt, verlangsamt PS1 Sie.

Anstatt komplett zu deaktivieren (wie von Dolan vorgeschlagen) oder das von Wilbert angebotene Skript zu verwenden, verwende ich eine "dumme PS1", die viel schneller ist.

Es verwendet (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\]# '

Bei meinem Cygwin ist dies schneller als Wilberts Antwort "fast_Git_PS1" - 200 ms vs. 400 ms, so dass ein wenig von Ihrer Prompt-Trägheit abgeschreckt wird.

Es ist nicht so ausgefeilt wie __git_ps1 - es ändert zum Beispiel die Eingabeaufforderung nicht, wenn Sie in das .git-Verzeichnis cd usw., aber für den normalen täglichen Gebrauch ist es gut und schnell.

Dies wurde auf Git 1.7.9 getestet (Cygwin, sollte aber auf jeder Plattform funktionieren).

5
sinelaw

Sie können auch eine sehr untergeordnete Leistungssteigerung erzielen, indem Sie die folgende Git-Konfiguration ändern:

git config --global status.submoduleSummary false

Bei der Ausführung des einfachen Befehls git status unter Windows 7 x64 hat der Computer mehr als 30 Sekunden benötigt. Nachdem diese Option definiert wurde, ist der Befehl sofort verfügbar.

Die Aktivierung der Git-eigenen Ablaufverfolgung, wie auf der folgenden Seite beschrieben, half mir dabei, den Ursprung des Problems zu finden, der sich in Ihrer Installation unterscheiden kann: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git -ist so langsam

4
Olivier

Wenn Sie Git von cmd verwenden, versuchen Sie, es von Git Bash aus auszuführen. __ In git.exe ist git.exe eigentlich ein Wrapper, der die richtige Umgebung bei jedem Start einrichtet und erst dann die echte git.exe startet. Es kann bis zu doppelt so lange dauern, wie Sie benötigen, um das zu tun, was Sie möchten. Und Git Bash richtet die Umgebung nur beim Start ein.

2
Eugene Pakhomov

In meinem Fall war es tatsächlich Avast Antivirus, was dazu führte, dass Git Bash und sogar PowerShell wirklich langsam wurden.

Ich habe zuerst versucht, Avast für 10 Minuten zu deaktivieren, um zu sehen, ob es die Geschwindigkeit verbessert hat. Anschließend fügte ich in Avast das gesamte Git Bash-Installationsverzeichnis als Ausnahme für Lesen, Schreiben und Ausführen hinzu. In meinem Fall war das C:\Program Files\Git\*.

2
Mastergalen

Ich habe das gleiche Problem, dass Git für Windows (msysgit) unter Windows 7 x64 schon seit einiger Zeit als eingeschränktes Benutzerkonto ausgeführt wird.

Nach dem, was ich hier und an anderen Orten gelesen habe, scheint das allgemeine Thema das Fehlen von Administratorrechten und/oder der Benutzerkontensteuerung zu sein. Da die Benutzerkontensteuerung auf meinem System deaktiviert ist, ist die Erklärung, dass versucht wird, etwas im Verzeichnis der Programmdateien zu schreiben/zu löschen, für mich am sinnvollsten.

In jedem Fall habe ich mein Problem gelöst, indem ich die portable Version von Git 1.8 mit zipinstaller installiert habe. Beachten Sie, dass ich die .7z-Verteilungsdatei entpacken und als Zip-Datei neu packen musste, damit zipinstaller funktioniert. Ich musste dieses Verzeichnis auch manuell zu meinem Systempfad hinzufügen.

Die Leistung ist jetzt in Ordnung. Obwohl es im Program Files (x86)-Verzeichnis installiert ist, für das ich als Benutzer mit eingeschränkter Berechtigung keine Berechtigungen habe, scheint es nicht das gleiche Problem zu sein.

Ich schreibe dies entweder der Tatsache zu, dass die portable Version etwas konservativer ist, wenn sie Dateien schreibt/löscht, was wahrscheinlich der Fall ist, oder auf das Upgrade von 1.7 auf 1.8. Ich werde nicht versuchen herauszufinden, welcher Grund der Grund ist, es genügt zu sagen, dass es jetzt viel besser funktioniert, einschließlich Bash.

2
Binary Phile

Kombinierte Antworten:

  1. Wilbert's - welche Informationen werden in PS1 aufgenommen
  2. sinelaws - (<branch_name>) oder (<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}\[email protected]\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

Ergebnis:

 frolowr@RWAMW36650 /c/projects/Elm-math-kids (master) $

2
rofrol

Zusätzlich zu diesen anderen Antworten habe ich Projekte mit mehreren Submodulen beschleunigt, indem parallele Submodul-Abrufe verwendet wurden (seit Git 2.8 Anfang 2016).

Dies kann mit git fetch --recurse-submodules -j8 erfolgen und mit git config --global submodule.fetchJobs 8 eingestellt werden, oder wie viele Kerne Sie verwenden möchten/möchten.

2
codehearts

Nur das Deaktivieren von AMD Radeon Graphics (oder Intel Graphics) im Geräte-Manager hat mir geholfen.

 enter image description here

Ich habe die Antwort hier gefunden: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

2

Nichts davon konnte mir helfen. In meinem Szenario zeigte sich das Problem so:

  • Jeder ll-Befehl war langsam (die Ausführung dauerte etwa 3 Sekunden)
  • Jeder nachfolgende ll-Befehl wurde sofort ausgeführt, , jedoch nur, wenn er sich innerhalb von 45 Sekunden vom vorherigen ls-Befehl befand.

Beim Debuggen mit Process Monitor wurde festgestellt, dass vor jedem Befehl eine DNS-Anforderung vorlag.

Sobald ich also meine Firewall (in meinem Fall Comodo) deaktiviert habe und den Befehl ausführen lasse, ist das Problem weg. Und es kommt nicht zurück, wenn die Firewall wieder eingeschaltet wurde. Bei der frühesten Gelegenheit werde ich diese Antwort mit weiteren Details dazu aktualisieren, welcher Prozess eine blockierende DNS-Anfrage durchführte und was das Ziel war.

BR, G

1
George

In meinem Fall wurde die Git Bash-Verknüpfung auf Start in:%HOMEDRIVE%%HOMEPATH% gesetzt (Sie können dies überprüfen, indem Sie mit der rechten Maustaste auf Git Bash klicken und Eigenschaften auswählen). Dies war das Netzlaufwerk. 

Die Lösung besteht darin, auf %HOME% zu verweisen. Wenn Sie es nicht haben, können Sie es in den Umgebungsvariablen einrichten. Jetzt sollte Git Bash blitzschnell sein.

0
mahacoder

Ein Kollege von mir hatte Probleme mit Git unter Windows (7). git statuscheckout und add waren schnell, aber git commit dauerte lange.

Wir versuchen immer noch, die Hauptursache dafür zu finden, aber das Klonen des Repositorys in einen neuen Ordner hat sein Problem behoben.

0
mrcl

Wie viele sagten, liegt dies daran, dass stash ein Shell-Skript unter Windows ist, aber seit Git 2.18.0 hat das Windows-Installationsprogramm eine Option für eine experimentelle Funktion einer viel schnelleren (~ 90%) integrierten Version von stash - . https://github.com/git-for-windows/build-extra/pull/203 .

0
bergmeister

Ich hatte auch ein Problem mit git PS1 Langsamkeit, obwohl ich lange Zeit dachte, es sei ein Datenbankgrößenproblem (großes Repository) und versuchte verschiedene git gc-Tricks und suchte nach anderen Gründen, genau wie Sie. In meinem Fall war das Problem jedoch folgende Zeile:

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
}

Der git status für jede Befehlszeilenstatuszeile war langsam. Autsch. Es war etwas, was ich von Hand geschrieben habe. Ich habe gesehen, dass dies ein Problem war, als ich es versuchte

export PS1='$'

wie hier in einer Antwort erwähnt. Die Befehlszeile war blitzschnell.

Jetzt benutze ich das:

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
    ...

Aus dem Stack Overflow post PS1 Zeile mit git current branch und colors und es funktioniert einwandfrei. Habe wieder eine schnelle Git-Kommandozeile.

0
Koshmaar