Git Bash działa wyjątkowo wolno w systemie Windows 7 x64

Korzystałem z Git zarówno w systemie Windows, jak i Ubuntu podczas opracowywania małego projektu, często przerzucając się między nimi. Problem polega na tym, że Git Bash konsekwentnie staje się wolny.

Kiedy mówię powoli, mam na myśli, że bieganie cdzajmuje od 8 do 25 sekund, wykonywanie gitpoleceń trwa od 5 do 20 sekund, a lsczasem może trwać nawet do 30 sekund. Nie trzeba dodawać, że nie jest to zabawne, nie mówiąc już o bezproduktywności. Wiem, że Git działa wolniej w systemie Windows, ale jest to śmieszne.

Jedynym rozwiązaniem, które zadziałało - tymczasowo - było wyłączenie połączenia sieciowego (jak sugerowano w tej odpowiedzi ), uruchomienie Git Bash, a następnie ponowne połączenie. Czasami działa to szybko przez kilka dni po wykonaniu tej czynności, ale wydajność zawsze się pogarsza. Przeszukiwałem grupę dyskusyjną msysgit, przepełnienie stosu, listę problemów msysgit itp. Od tygodni, ale nie byłem w stanie znaleźć rozwiązań, które działają.

Do tej pory próbowałem:

• Dodawanie folderów Git i projektów do listy wykluczeń skanera antywirusowego
• Całkowite wyłączenie mojego skanera antywirusowego (Kaspersky IS 2011)
• Zapewnianie, że program Outlook nie działa (Outlook 2007)
• Zamykanie wszystkich innych aplikacji
• Uruchamianie Git Bash jako administrator
• Wyłączanie połączenia sieciowego, uruchamianie Git Bash i utrzymywanie połączenia wyłączone
• Wyłączanie połączenia sieciowego, uruchamianie Git Bash, ponowne włączanie połączenia (działa tylko sporadycznie)
• Bieganie git gc
• I kombinacje powyższych

Czytałem, że kilka osób odniosło sukces, uniemożliwiając ukończenie Bash, ale idealnie chciałbym zachować tę aktywność. Wersja msysgit to 1.7.3.1-Preview20101002, a system operacyjny to Windows 7 x64. Uruchamianie tych samych rzeczy w systemie Linux jest błyskawicznie szybkie. Używałbym wyłącznie Linuksa, ale muszę też uruchamiać rzeczy w Windowsie (niektóre aplikacje, testy itp.).

Czy ktoś napotkał podobny problem? Jeśli tak, jaki był problem podstawowy i jakie było rozwiązanie (jeśli w ogóle)?

Dotyczy to nie tylko repozytoriów Git, ale dla porównania, repozytoria, z których korzystam z Git, są dość małe: maksymalnie 4-50 plików.

Możesz znacznie przyspieszyć Git w systemie Windows, uruchamiając trzy polecenia, aby ustawić niektóre opcje konfiguracji:

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

Uwagi:

• core.preloadindex wykonuje równolegle operacje systemu plików, aby ukryć opóźnienia (aktualizacja: domyślnie włączona w Git 2.1)

• core.fscache naprawia problemy UAC, więc nie trzeba uruchamiać Gita jako administrator (aktualizacja: domyślnie włączona w Git dla Windows 2.8)

• gc.auto minimalizuje liczbę plików w .git /

Czy masz informacje Git wyświetlane w wierszu polecenia Bash? Jeśli tak, może przypadkowo wykonujesz za dużo pracy przy każdym poleceniu. Aby przetestować tę teorię, wypróbuj następującą tymczasową zmianę w Bash:

export PS1='$'

Mój katalog domowy Windows znajduje się w sieci i podejrzewałem, że polecenia Git Bash szukały go najpierw. Rzeczywiście, kiedy spojrzałem $PATH, /h/binnajpierw wymieniono , gdzie /hjest udział na serwerze plików Windows, chociaż /h/binnie istnieje.
Zredagowałem /etc/profilei skomentowałem polecenie eksportu, które stawia je na pierwszym miejscu $PATH:

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

Dzięki temu moje polecenia działały znacznie szybciej, prawdopodobnie dlatego, że Git Bash nie szuka już w sieci plików wykonywalnych. Mój /etc/profilebył c:\Program Files (x86)\Git\etc\profile.

Odkryłem, że dysk sieciowy jest problemem z wydajnością. HOMEwskazywał na wolny udział sieciowy. Nie mogłem zastąpić, HOMEDRIVEale to nie jest problem z tego, co widziałem.

Ustaw zmienną środowiskową, klikając prawym przyciskiem myszy komputer na pulpicie -> właściwości -> Zaawansowane ustawienia systemowe -> Zmienne środowiskowe Dodaj do sekcji Zmienne użytkownika

HOME=%USERPROFILE%

W rozszerzeniu odpowiedzi Chrisa Dolana zastosowałem następujące PS1ustawienie alternatywne . Po prostu dodaj fragment kodu do ~ / .profile (w 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\]
$ '

Zachowuje to zaletę kolorowej powłoki i wyświetlania bieżącej nazwy gałęzi (jeśli jest w repozytorium Git), ale na mojej maszynie jest znacznie szybszy, od ~ 0,75 s do 0,1 s.

Jest to oparte na tym blogu .

Chociaż problem może dotyczyć sieci, osobiście przyspieszyłem git statusdziesięciokrotnie moje połączenia lokalne (7+ sekund do 700 ms), dokonując dwóch modyfikacji. Jest to repozytorium o pojemności 700 MB z 21 000 plików i nadmierną liczbą dużych plików binarnych.

Jednym z nich jest włączenie wstępnego ładowania indeksu równoległego. Z wiersza polecenia:

git config core.preloadindex true
Zmieniło się to time git statusz 7 sekund do 2,5 sekundy.

Aktualizacja!

Poniższe nie jest już konieczne. Łatka naprawiła to od wersji mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Jednak należy włączyć poprawkę, wpisując
git config core.fscache true

Wyłączyłem także UAC i sterownik „luafv” (wymagane ponowne uruchomienie). Wyłącza to sterownik w systemie Windows Vista, 7 i 8, który przekierowuje programy próbujące zapisywać do lokalizacji systemowych, a zamiast tego przekierowuje dostęp do katalogu użytkownika.

Aby zobaczyć dyskusję na temat tego, jak wpływa to na wydajność Gita, przeczytaj tutaj: https://code.google.com/p/msysgit/issues/detail?id=320

Aby wyłączyć ten sterownik, w regedit zmień klawisz „start” na HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv4, aby wyłączyć sterownik. Następnie ustaw UAC na najniższe ustawienie, „nigdy nie powiadamiaj”.

Jeśli wyłączenie tego sterownika powoduje, że jesteś ostrożny (powinien), alternatywa działa na dysku (lub partycji) innej niż partycja systemowa. Najwyraźniej sterownik działa tylko w przypadku dostępu do plików na partycji systemowej. Mam drugi dysk twardy i widzę identyczne wyniki po uruchomieniu z tą modyfikacją rejestru na moim dysku C, jak robię to bez niego na dysku D.

Ta zmiana trwa time git statusod 2,5 sekundy do 0,7 sekundy.

Możesz także śledzić https://github.com/msysgit/git/pull/94 i https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b, aby sprawdzić, jakie dodatkowe prace są prowadzone w związku z problemami z szybkością w systemie Windows .

Wygląda na to, że całkowite odinstalowanie Gita, ponowne uruchomienie (klasyczne lekarstwo na system Windows) i ponowna instalacja Git była lekarstwem. Wyczyściłem również wszystkie pliki konfiguracyjne bash, które pozostały (zostały ręcznie utworzone). Wszystko znów jest szybkie.

Jeśli z jakiegoś powodu ponowna instalacja nie jest możliwa (lub pożądana), to zdecydowanie spróbowałbym zmienić zmienną PS1 wymienioną w odpowiedzi Chrisa Dolana ; spowodowało znaczne przyspieszenie niektórych operacji.

Rozwiązałem mój wolny problem z Git na Windows 7 x64, uruchamiając cmd.exe z „Uruchom jako administrator”.

Zauważyłem przyzwoitą poprawę, ustawiając core.preloadindex na true zgodnie z zaleceniami tutaj .

Jak zauważono w odpowiedziach Chrisa Dolana i Wilberta, PS1 spowalnia cię .

Zamiast całkowicie wyłączać (jak sugeruje Dolan) lub używać skryptu oferowanego przez Wilberta, używam „głupiego PS1”, który jest znacznie szybszy.

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

W moim Cygwinie jest to szybsze niż odpowiedź „fast_Git_PS1” Wilberta - 200 ms w porównaniu do 400 ms, więc goli trochę twoją szybką powolność.

Nie jest tak wyrafinowany jak __git_ps1- na przykład nie zmienia monitu, gdy przechodzisz do katalogu .git itp., Ale do normalnego codziennego użytku jest wystarczająco dobry i szybki.

Zostało to przetestowane na Git 1.7.9 (Cygwin, ale powinno działać na dowolnej platformie).

Możesz również zyskać bardzo subtelny wzrost wydajności, zmieniając następującą konfigurację Git:

git config --global status.submoduleSummary false

Po uruchomieniu prostej git statuskomendy w systemie Windows 7 x64 uruchomienie komputera zajęło mi ponad 30 sekund. Po zdefiniowaniu tej opcji polecenie jest natychmiastowe.

Aktywacja własnego śledzenia Gita, jak wyjaśniono na poniższej stronie, pomogła mi znaleźć źródło problemu, który może różnić się w twojej instalacji: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- powolny

Miałem ten sam problem, zarówno w Git Bash, jak i Git GUI. Oba programy ładnie działają, ale potem losowo zwolniły do ​​indeksowania i nie mogłem zrozumieć, dlaczego.

Jak się okazuje, był to Avast. Avast spowodował dziwne rzeczy, które przydarzyły się różnym programom (w tym programom, które piszę), więc wyłączyłem go na sekundę i oczywiście Bash działa teraz tak szybko, jak na Linuksie. Właśnie dodałem folder plików programu Git ( C:\Program Files\Git) do listy wykluczeń Avast, a teraz działa tak szybko, jak w Linuksie.

I tak, zdaję sobie sprawę, że oprogramowanie antywirusowe nie było problemem w oryginalnym poście, ale po prostu umieszczę to tutaj na wypadek, gdyby było to przydatne dla kogoś.

Oprócz tych innych odpowiedzi przyspieszyłem projekty z wieloma podmodułami, używając równoległego pobierania modułów (od Gita 2.8 na początku 2016 r.).

Można tego dokonać git fetch --recurse-submodules -j8i ustawić za pomocą git config --global submodule.fetchJobs 8, lub niezależnie od tego, ile rdzeni masz / chcesz użyć.

Jeśli używasz Git z cmd, spróbuj uruchomić go z Git Bash. W cmd git.exe to tak naprawdę opakowanie, które konfiguruje właściwe środowisko za każdym razem, gdy go uruchamiasz, a dopiero potem uruchamia prawdziwy git.exe. Może to zająć nawet dwa razy więcej czasu, niż potrzeba, aby zrobić to, co chcesz. A Git Bash konfiguruje środowisko dopiero po uruchomieniu.

Pomogło mi tylko wyłączenie grafiki AMD Radeon (lub Intel Graphics) w Menedżerze urządzeń.

Znalazłem odpowiedź tutaj: /superuser/1160349/git-is-extremely-slow-on-windows# =

Połączone odpowiedzi:

1. Wilbert's - jakie informacje zawrzeć w PS1
2. sinelaw's - (<branch_name>)lub(<sha>)

# /unix/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# /unix/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")"

# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# /programming/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}\] $ '

Wynik:

Ten sam problem z uruchomieniem Git dla Windows (msysgit) na Windows 7 x64 jako konto z ograniczonym kontem użytkownika od dłuższego czasu.

Z tego, co przeczytałem tutaj i innych miejscach, wspólnym tematem wydaje się być brak uprawnień administracyjnych i / lub UAC. Ponieważ UAC jest wyłączony w moim systemie, wyjaśnienie, że próbuje coś zapisać / usunąć coś w katalogu plików programów, jest dla mnie najbardziej sensowne.

W każdym razie rozwiązałem problem, instalując przenośną wersję Git 1.8 z programem zipinstaller. Zauważ, że musiałem rozpakować plik dystrybucyjny .7z i ponownie go spakować jako plik ZIP, aby zipinstaller działał. Musiałem też ręcznie dodać ten katalog do ścieżki systemowej.

Wydajność jest teraz w porządku. Mimo że jest zainstalowany w Program Files (x86)katalogu, do którego nie mam uprawnień jako ograniczony użytkownik, wydaje się, że nie cierpi z powodu tego samego problemu.

Przypisuję to albo faktowi, że wersja przenośna jest nieco bardziej konserwatywna w przypadku zapisywania / usuwania plików, co prawdopodobnie ma miejsce, albo aktualizacji z wersji 1.7 do 1.8. Nie zamierzam określać, który jest powodem, wystarczy powiedzieć, że teraz działa znacznie lepiej, w tym Bash.

W moim przypadku był to program antywirusowy Avast prowadzący do Git Bash, a nawet PowerShell stał się naprawdę wolny.

Najpierw próbowałem wyłączyć Avast na 10 minut, aby sprawdzić, czy poprawiła prędkość i tak się stało. Następnie dodałem cały katalog instalacyjny Git Bash jako wyjątek w Avast, do odczytu, zapisu i wykonania. W moim przypadku tak było C:\Program Files\Git\*.

Nic z powyższych nie było w stanie mi pomóc. W moim scenariuszu problem wyglądał następująco:

• Każde llpolecenie działało powoli (wykonanie trwało około 3 sekund)
• Każde kolejne llpolecenie zostało wykonane natychmiast, ale tylko w ciągu 45 sekund od poprzedniego polecenia ls .

Jeśli chodzi o debugowanie za pomocą Monitora procesów , okazało się, że przed każdym poleceniem było żądanie DNS.

Gdy tylko wyłączyłem zaporę (w moim przypadku Comodo) i pozwoliłem, aby polecenie wykonało problem, problem zniknął. I nie wraca z powrotem, gdy zapora została ponownie włączona. Przy najbliższej okazji zaktualizuję tę odpowiedź, podając więcej szczegółów na temat tego, co proces blokował żądanie DNS i jaki był cel.

BR, G

W moim przypadku skrót Git Bash został ustawiony na Start in:%HOMEDRIVE%%HOMEPATH%(możesz to sprawdzić, klikając prawym przyciskiem myszy Git Bash i wybierając właściwości). To był dysk sieciowy.

Rozwiązaniem jest wskazanie tego %HOME%. Jeśli go nie masz, możesz ustawić go w zmiennych środowiskowych, a teraz Git Bash powinien być błyskawiczny.

Miałem również problem ze spowolnieniem git PS1, chociaż przez długi czas myślałem, że to problem z wielkością bazy danych (duże repozytorium) i próbowałem różnych git gcsztuczek, i szukałem innych powodów, takich jak ty. Jednak w moim przypadku problemem był ten wiersz:

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
}

Wykonanie git statusdla każdej linii statusu linii poleceń było powolne. Auć. To było coś, co napisałem ręcznie. Widziałem, że to był problem, kiedy próbowałem

export PS1='$'

jak wspomniano w jednej odpowiedzi tutaj. Linia poleceń była błyskawiczna.

Teraz używam tego:

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

Z linii Przepełnienie stosu po linii PS1 z bieżącym odgałęzieniem i kolorami i działa dobrze. Znowu masz szybką linię poleceń Git.

Mój współpracownik miał problemy z Git na Windowsie (7) git status checkouti addbył szybki, ale git commitzajął wieki.

Nadal próbujemy znaleźć przyczynę tego problemu, ale klonowanie repozytorium w nowym folderze naprawiło jego problem.

Jak wielu powiedziało, wynika to z faktu, że stashjest to skrypt powłoki w systemie Windows, ale od wersji Git 2.18.0 instalator Windows ma opcję eksperymentalnej funkcji znacznie szybszej (~ 90%) wbudowanej wersji skrytki - https: / /github.com/git-for-windows/build-extra/pull/203 .