it-swarm-tr.com

Git Bash, Windows 7 x64'te son derece yavaştır

Git'i hem Windows hem de Ubuntu'da küçük bir projenin gelişimi sırasında kullanıyorum, ikisi arasında sık sık geri döndüm. Sorun şu ki Git Bash sürekli yavaşlıyor.

Yavaş derken, cd komutunu çalıştırmanın 8-25 saniye arasında bir yerde, git komutunu çalıştırması 5-20 saniyede, ls öğesinde bazen 30 saniyeye kadar sürebilir. Söylemeye gerek yok, bu eğlenceli değil, verimsiz söz değil. Git'in Windows'ta daha yavaş olduğunu biliyorum, ancak bu çok saçma.

Çalışmış olan tek çözüm - geçici olarak - benim için ağ bağlantımı devre dışı bırakmaktı ( bu cevabında önerildiği gibi), Git Bash'i başlatmak ve sonra yeniden bağlanmaktı. Bazen bunu yaptıktan sonra günlerce hızlı bir şekilde çalışmaya devam eder, ancak performans sonunda daima düşer. Haftalar boyunca msysgit tartışma grubu, Stack Overflow, msysgit yayın listesi, vb. İle dolaştım, ancak işe yarayan çözümleri bulamadım.

Şimdiye kadar denedim:

  • Git ve proje klasörlerini virüs tarayıcısının dışlama listesine ekleme
  • Virüs tarayıcımı tamamen devre dışı bırakma (Kaspersky IS 2011)
  • Outlook'un çalışmadığından emin olma (Outlook 2007)
  • Diğer tüm uygulamaları kapatma
  • Git Bash'i yönetici olarak çalıştırmak
  • Ağ bağlantısını devre dışı bırakma, Git Bash'i başlatma ve bağlantıyı devre dışı bırakma
  • Ağ bağlantısını devre dışı bırakma, Git Bash'i başlatma, bağlantıyı yeniden etkinleştirme (yalnızca ara sıra çalışır)
  • git gc çalıştırılıyor
  • Ve yukarıdakilerin kombinasyonları

Bash'in tamamlanmasını engelleyen birkaç insanın başarılı olduğunu okudum, ama ideal olarak bunu aktif tutmak istiyorum. Msysgit sürümü 1.7.3.1 önizleme20101002 ve işletim sistemi Windows 7 x64'dür. Aynı şeyleri Linux üzerinde çalıştırmak tahmin edilebileceği gibi çok hızlı bir şekilde şimşek çakıyor. Sadece Linux kullanırdım, ancak Windows'ta da bazı şeyler çalıştırmam gerekiyor (bazı uygulamalar, testler, vb.).

Benzer bir sorunla karşılaşan var mı? Eğer öyleyse, altta yatan sorun neydi ve çözüm neydi (varsa)?

Bu, yalnızca Git depolarının ötesine uzanır, ancak yalnızca referans olması için Git'i kullandığım depolar oldukça küçüktür: ~ maksimum 4-50 dosya.

384
Gemini14

Git'in tamamen kaldırılması, yeniden başlatılması (klasik Windows kürü) ve Git'in yeniden kurulmasının tedavisi olduğu anlaşılıyor. Ayrıca, kalan tüm bash config dosyalarını da sildim (manuel olarak oluşturuldular). Her şey yine hızlı.

Herhangi bir nedenle yeniden yükleme mümkün değilse (veya isteniyorsa), kesinlikle Chris Dolan'ın cevabı ; belirli operasyonlarda önemli hızlanmalarla sonuçlandı.

15
Gemini14

Bazı yapılandırma seçeneklerini ayarlamak için üç komut çalıştırarak Git'i Windows'ta önemli ölçüde hızlandırabilirsiniz:

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

Notlar:

  • core.preloadindex, gecikme süresini gizlemek için dosya sistemi paralel çalışır (güncelleme: Git 2.1'de varsayılan olarak etkindir)

  • core.fscache, UAC sorunlarını düzeltir; böylece Git'i yönetici olarak çalıştırmanız gerekmez (güncelleme: Windows 2.8 için Git'te varsayılan olarak etkindir)

  • gc.auto, .git/içindeki dosya sayısını en aza indirir.

384
shoelzer

Bash isteminizde gösterilen Git bilginiz var mı? Öyleyse, belki istemeyerek her komutta çok fazla iş yapıyorsun. Bu teoriyi test etmek için Bash'de aşağıdaki geçici değişimi deneyin:

export PS1='$'
85
Chris Dolan

Windows giriş dizinim ağda ve Git Bash komutlarının önce oraya baktığından şüphelendim. Yeterince, $ PATH'a baktığımda, önce/h/bin yazdı,/h/bin olmasa da,/h Windows dosya sunucusundaki bir paylaşımdı./Etc/profile dosyasını düzenledim ve $ PATH içine koyan export komutunu yorumladım:

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

Bu, komutlarımın çok daha hızlı çalışmasını sağladı, çünkü Git Bash artık çalıştırılabilir dosyalar için ağa bakmıyor./Etc/profile benim c:\Program Files (x86)\Git\etc\profile oldu.

72
Rob Johnson

Ağ sürücüsünün performans sorunu olduğunu gördüm. HOME yavaş bir ağ paylaşımına işaret ediyordu . HOMEDRIVE işlevini geçersiz kılamadım ancak bu gördüğümden bir sorun değil.

Ortam değişkenini sağ tıklatarak masaüstünde Bilgisayarınızdan seçin -> özellikler -> Gelişmiş sistem ayarları -> Ortam Değişkenleri

HOME=%USERPROFILE%
32
MichaelK

Sorununuz ağ tabanlı olsa da, kişisel olarak iki değişiklik yaptım yerel git status çağrılarımı on kat (7+ saniyeden 700 ms'ye kadar) çağırdı. Bu, 21.000 dosya ve fazla sayıda büyük ikili dosya içeren 700 MB'lık bir depodadır.

Biri paralel endeks önyüklemelerini mümkün kılıyor. Komut isteminden:

git config core.preloadindex true
Bu, time git status değerini 7 saniyeden 2,5 saniyeye değiştirdi.

Güncelleştirme!

Aşağıdaki artık gerekli değildir. Bir yama bunu mysysgit 1.9.4'ten itibaren düzeltti.
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Ancak, yazarak düzeltmeyi etkinleştirmeniz gerekir.
git config core.fscache true

Ayrıca UAC ve "luafv" sürücüsünü de devre dışı bıraktım (yeniden başlatma gerekli). Bu, Windows Vista, 7 ve 8'deki, sistem konumlarına yazmaya çalışan programları yönlendiren ve bunun yerine bu erişimleri bir kullanıcı dizinine yönlendiren bir sürücüyü devre dışı bırakır.

Bunun Git performansını nasıl etkilediğiyle ilgili bir tartışma görmek için burayı okuyun: https://code.google.com/p/msysgit/issues/detail?id=320

Bu sürücüyü devre dışı bırakmak için, regedit'de, sürücüyü devre dışı bırakmak için HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv adresindeki "start" tuşunu değiştirin. Ardından, UAC'yi "asla bildirimde bulunma" en düşük ayara getirin.

Bu sürücünün devre dışı bırakılması sizi temkinli yaparsa (olması gerektiği), sistem bölümünüzden farklı bir sürücüde (veya bölümde) bir alternatif çalışıyordur. Görünüşe göre sürücü sadece sistem bölümündeki dosya erişiminde çalışıyor. İkinci bir sabit sürücüm var ve C sürücümdeki bu kayıt defteri değişikliği ile çalıştığımda D sürücüsünde olmadığı gibi aynı sonuçları görüyorum.

Bu değişiklik time git status öğesini 2,5 saniyeden 0,7 saniyeye düşürüyor.

Ayrıca https://github.com/msysgit/git/pull/94 ve https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b sayfasını takip etmek isteyebilirsiniz Windows'ta hız sorunları için çalışmalar devam etmektedir.

22
Jeff Lamb

Chris Dolan'ın cevabına ek olarak, aşağıdaki alternatif PS1 ayarını kullandım. Kod parçasını ~/.profile dosyasına eklemeniz yeterlidir (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\]
$ '

Bu, renkli bir Kabuğun yararını ve geçerli dal adının görüntülenmesini (Git deposundaysa) korur, ancak makinemde ~ 0.75 s'den 0.1 s'ye önemli ölçüde daha hızlıdır.

Bu bu blog yazısına dayanmaktadır.

21
Wilbert

Cmd.exe'ye "Yönetici olarak çalıştır" ile başlatarak yavaş Git sorunumu Windows 7 x64'te çözdüm.

10

Core.preloadindex'i burada tavsiye edildiği şekilde doğru 'a ayarlayarak iyi bir gelişme gördüm.

8
Andy

Hem Git Bash hem de Git GUI'de de aynı problemi yaşıyordum. Her iki program da güzelce çalışıyor, ancak daha sonra rasgele bir sürüngene yavaşladılar ve nedenini bulamadım.

Görünüşe göre Avast idi. Avast, çeşitli programlarda (yazdığım programlar dahil) garip şeyler olmasına neden oldu, bu yüzden bir saniye için devre dışı bıraktım ve tabii ki, Bash artık Linux'ta olduğu kadar hızlı çalışıyor. Git program dosyaları klasörünü (C:\Program Files\Git) Avast dışlama listesine ekledim ve şimdi Linux'ta olduğu kadar hızlı çalışıyor.

Ve evet, antivirüs yazılımının asıl gönderideki sorun olmadığını fark ettim, ancak birini işe yararsa diye buraya koyacağım.

5
Nkosi Dean

Chris Dolan ve Wilbert'in cevaplarında belirtildiği gibi, PS1 sizi yavaşlatır.

Tamamen devre dışı bırakmak (Dolan tarafından önerildiği gibi) veya Wilbert tarafından sunulan senaryoyu kullanmak yerine, çok daha hızlı bir "aptal PS1" kullanıyorum.

(git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null kullanır:

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

Cygwin'imde bu, Wilbert'in "fast_Git_PS1" cevabından - 200 ms'e karşılık 400 ms'den daha hızlı, bu yüzden istemi halsizliğinizi biraz azaltıyor.

__git_ps1 kadar karmaşık değildir - örneğin, .git dizinine vb. Girdiğinizde Bilgi İstemi'ni değiştirmez, ancak normal günlük kullanım için yeterince iyi ve hızlıdır.

Bu Git 1.7.9'da test edildi (Cygwin, ancak herhangi bir platformda çalışması gerekiyor).

5
sinelaw

Aşağıdaki Git yapılandırmasını değiştirerek çok daha düşük bir performans artışı elde edebilirsiniz:

git config --global status.submoduleSummary false

Windows 7 x64'te basit git status komutunu çalıştırırken bilgisayarımın çalışması 30 saniyeden fazla sürdü. Bu seçenek tanımlandıktan sonra komut hemen verilir.

Git'in aşağıdaki sayfada açıklandığı gibi kendi izini etkinleştirmek, kurulumunuzda farklı olabilecek sorunun Kökeni bulmama yardımcı oldu: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git - çok yavaş

4
Olivier

Git'i cmd'den kullanıyorsanız, Git Bash'den çalıştırmayı deneyin. __ cmd'de, git.exe aslında her başlatışınızda doğru ortamı ayarlayan bir sarmalayıcıdır ve yalnızca o zaman gerçek git.exe'yi başlatır. Ne istersen yapman gerekenden iki kat fazla zaman alabilir. Git Bash çevreyi ancak başladığında kurar.

2
Eugene Pakhomov

Benim durumumda, aslında Git Bash'e yol açan Avast antivirüsüydü ve PowerShell bile gerçekten yavaşlıyordu.

Önce hızını artırıp artırmadığını görmek için Avast'ı 10 dakika devre dışı bırakmayı denedim. Daha sonra tüm Git Bash kurulum dizinini Avast'ta Okuma, Yazma ve Çalıştırma için bir istisna olarak ekledim. Benim durumumda bu C:\Program Files\Git\* idi.

2
Mastergalen

Windows 7 x64'te Git for Windows'u (msysgit) çalıştırırken de aynı sorunla sınırlı bir kullanıcı hesabıyla karşılaştım.

Burada ve diğer yerlerde okuduklarımdan, ortak tema idari ayrıcalıkların ve/veya UAC'nin olmaması gibi görünüyor. Benim sistemimde UAC kapalı olduğundan, program dosyaları dizininde bir şey yazmaya/silmeye çalıştığının açıklaması benim için en anlamlı olanıdır.

Her durumda, Git 1.8'in taşınabilir sürümünü zipinstaller ile yükleyerek sorunumu çözdüm. .7z dağıtım dosyasını paketinden çıkarmak ve zipinstaller'ın çalışması için Zip dosyası olarak yeniden paketlemem gerektiğine dikkat edin. Ayrıca bu dizini sistem yoluma el ile eklemek zorunda kaldım.

Performans şimdi iyi. Sınırlı bir kullanıcı olarak iznim olmayan Program Files (x86) dizininde yüklü olmasına rağmen, aynı sorundan muzdarip görünmüyor.

Bunu ya portatif versiyonun, muhtemelen durum olan dosyaları yazdığı/sildiği ya da 1.7'den 1.8'e yükselttiği için biraz daha muhafazakâr olduğu gerçeğine atfediyorum. Hangisinin nedenini tespit etmeye çalışmayacağım, şimdi Bash de dahil olmak üzere daha iyi çalıştığını söylemek yeterli.

2
Binary Phile

Birleşik cevaplar:

  1. Wilbert's - PS1'e hangi bilgileri dahil edersiniz?
  2. sinelaw's - (<branch_name>) veya (<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}\] $ '

Sonuç:

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

2
rofrol

Bu diğer cevaplara ek olarak, paralel alt modül alımını kullanarak (2016'nın başlarında Git 2.8'den beri) birden fazla alt modüle sahip projeleri hızlandırdım.

Bu, git fetch --recurse-submodules -j8 ile yapılabilir ve git config --global submodule.fetchJobs 8 ile ya da kullanmak istediğiniz/kullanmak istediğiniz birçok çekirdekle ayarlanabilir.

2
codehearts

Yalnızca AMD Radeon Graphics'i (veya Intel Graphics'i) Aygıt Yöneticisi'nde kapatmak yardımcı oldu.

 enter image description here

Cevabı burada buldum: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

2

Yukarıdakilerin hiçbiri bana yardım edemedi. Benim senaryomda mesele şu şekilde kendini gösteriyordu:

  • Herhangi bir ll komutu yavaştı (yürütülmesi yaklaşık 3 saniye sürdü)
  • Ardından gelen herhangi bir ll komutu anında, ancak yalnızca önceki ls komutundan sonra 45 saniye içinde gerçekleştirilirse gerçekleştirildi.

İşlem İzleyicisi ile hata ayıklamaya gelince, her komuttan önce bir DNS isteği olduğu bulundu.

Böylece güvenlik duvarımı devre dışı bıraktığımda (durumumda Comodo) ve komutun çalışmasına izin verdim. Güvenlik duvarı tekrar açıldığında da geri dönmüyor. İlk fırsatta, bu yanıtı hangi sürecin engelleyici bir DNS isteğini gerçekleştirdiği ve hedefin ne olduğu hakkında daha fazla ayrıntıyla güncelleyeceğim.

BR G

1
George

Benim durumumda Git Bash kısayolu Start in:%HOMEDRIVE%%HOMEPATH% olarak ayarlandı (bunu Git Bash'i sağ tıklayıp özellikleri seçerek kontrol edebilirsiniz). Bu ağ sürücüsü idi. 

Çözüm, %HOME% 'ya işaret etmektir. Eğer sizde yoksa, ortam değişkenlerinde ayarlayabilirsiniz ve şimdi Git Bash çok hızlı bir şekilde şimşek çakıyor olmalı.

0
mahacoder

Bir meslektaşım Windows'ta Git ile ilgili sorunlar yaşadı (7) git statuscheckout ve add hızlıydı, ancak git commit yaş aldı.

Bunun nedenini hala bulmaya çalışıyoruz, ancak depoyu yeni bir klasöre klonlamak sorununu çözdü.

0
mrcl

Birçok kişinin dediği gibi, bunun stash'ın Windows'ta bir Shell betiği olması nedeniyle, ancak Git 2.18.0'dan bu yana, Windows yükleyici, daha hızlı (~% 90) bir stash -.__ sürümünün deneysel bir özelliği için bir seçeneğe sahip. . https://github.com/git-for-windows/build-extra/pull/203 .

0
bergmeister

Git PS1 yavaşlığında da sorun yaşadım, uzun zamandır bunun bir veri tabanı boyutu sorunu (büyük depo) olduğunu düşünüyordum ve çeşitli git gc numaralarını deniyordum ve tıpkı sizin gibi başka sebepler arıyorlardı. Ancak, benim durumumda, sorun bu satırdı:

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
}

Her komut satırı durum satırı için git status yapmak yavaştı. Ahh. Elle yazdığım bir şeydi. Bunu denediğimde bunun bir sorun olduğunu gördüm.

export PS1='$'

burada bir cevapta belirtildiği gibi. Komut satırı çok hızlı yıldırıyordu.

Şimdi bunu kullanıyorum:

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

Yığın Taşması sonrası PS1 hattından git akım dalı ve renkler ile çalışıyor ve düzgün çalışıyor. Yine hızlı bir Git komut satırı var.

0
Koshmaar