Git / Bash é extremamente lento no Windows 7 x64

Eu tenho usado o Git no Windows e no Ubuntu durante o desenvolvimento de um projeto pequeno, frequentemente alternando entre os dois. O problema que estou tendo é que o Git / Bash se torna lento. Quando digo devagar, quero dizer que o cd em execução leva de 8 a 25 segundos, a execução de comandos do git leva de 5 a 20 segundos e o ls pode levar até 30 segundos, às vezes. Escusado será dizer que isso não é divertido, para não mencionar improdutivo. Eu sei que o Git é mais lento no Windows, mas isso é ridículo.

A única solução que funcionou – temporariamente – para mim foi desativar minha conexão de rede (como sugerido nesta resposta ), iniciar o git e, em seguida, reconectar. Às vezes, ele continua a funcionar rapidamente por dias depois de fazer isso, mas o desempenho sempre degrada eventualmente. Eu vasculhei o grupo de discussão msysgit, SO, lista de problemas msysgit, etc. por semanas, mas não consegui encontrar soluções que funcionassem.

Até agora, tentei:

  • Adicionando git & project folders à lista de exclusão de scanners de vírus
  • Desativando meu scanner de vírus completamente (Kaspersky IS 2011)
  • Garantindo que o Outlook não esteja em execução (Outlook 2007)
  • Desligando todos os outros aplicativos
  • Executando o git como administrador
  • Desativando a conexão de rede, iniciando o git e mantendo a conexão desativada
  • Desativando a conexão de rede, iniciando o git, reativando a conexão (funciona apenas ocasionalmente)
  • Executando git gc
  • E combinações do acima

Eu li que algumas pessoas tiveram sucesso ao desativar a conclusão do bash, mas o ideal é que eu gostaria de manter isso ativo. A versão do msysgit é 1.7.3.1-preview20101002 e o sistema operacional é o Windows 7 x64. Executar as mesmas coisas no Linux é, previsivelmente, muito rápido. Eu usaria o Linux exclusivamente, mas também preciso executar coisas no Windows (determinados aplicativos, testes, etc.).

Alguém já encontrou um problema semelhante? Em caso afirmativo, qual foi o problema subjacente e qual foi a solução (se houver)?

Edit: Isso se estende além dos repositorys git, mas apenas para referência, os repositorys que eu tenho usado git têm sido bem pequenos: ~ 4-50 arquivos max.

Você pode acelerar significativamente o git no Windows executando três comandos para definir algumas opções de configuração:

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

Notas:

  • core.preloadindex faz operações do sistema de arquivos em paralelo para ocultar a latência (atualização: ativada por padrão no git 2.1)

  • core.fscache corrige problemas do UAC para que você não precise executar o git como admin (atualização: ativada por padrão no Git para Windows 2.8)

  • gc.auto minimiza o número de arquivos em .git /

Você tem informações do Git mostrando em seu prompt do Bash? Se assim for, talvez você esteja inadvertidamente fazendo muito trabalho em cada comando. Para testar essa teoria, tente a seguinte mudança temporária no Bash:

 export PS1='$' 

Meu diretório pessoal do Windows está na rede e desconfiei que os comandos do Git Bash estavam lá primeiro. De fato, quando eu olhei para o $ PATH, ele listou o / h / bin primeiro, onde / h é um compartilhamento em um servidor de arquivos do Windows, mesmo que o / h / bin não exista. Eu editei / etc / profile e comentei o comando de exportação que o coloca primeiro em $ PATH:

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

Isso fez com que meus comandos rodassem muito mais rápido, provavelmente porque o Git Bash não está mais procurando na rede pelos executáveis. Meu / etc / profile era c: \ Arquivos de Programas (x86) \ Git \ etc \ profile.

Eu encontrei a unidade de rede foi o problema de desempenho. HOME apontava para um compartilhamento de rede lento. Eu não consegui anular o HOMEDRIVE mas isso não é um problema do que eu vi.

Defina a variável de ambiente clicando com o botão direito do mouse em seu computador na área de trabalho -> propriedades -> Configurações avançadas do sistema -> Variáveis ​​de ambiente Adicionar à seção Variáveis ​​do usuário

 HOME=%USERPROFILE% 

Enquanto seu problema pode ser baseado em rede, eu pessoalmente acelerou minhas chamadas locais de git status dez vezes (7 + segundos para 700ms), fazendo duas modificações. Este é um repository de 700mb com 21.000 arquivos e um número excessivo de arquivos binários grandes.

Uma está habilitando os pré-carregamentos de índice paralelo. Em um prompt de comando:
git config core.preloadindex true
Isso mudou o time git status do time git status de 7 segundos para 2,5 segundos.

Atualizar!

O seguinte não é mais necessário. Um patch corrigiu isso como do mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
No entanto, você deve habilitar a correção digitando
git config core.fscache true

Também desativei o UAC e o driver “luafv” (reboot necessária). Isso desativa um driver no windows vista, 7 e 8 que redireciona programas que tentam gravar em locais do sistema e, em vez disso, redireciona esses accesss para um diretório de usuários.

Para ver uma discussão sobre como isso afeta o desempenho do git, leia aqui: https://code.google.com/p/msysgit/issues/detail?id=320

Para desabilitar este driver, no regedit, altere a chave “start” em HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv para 4 para desabilitar o driver. Em seguida, coloque o UAC em sua configuração mais baixa, “never notify”.

Se a desativação desse driver deixar você cauteloso (deve), uma alternativa está sendo executada em uma unidade (ou partição) diferente da partição do seu sistema. Aparentemente, o driver só é executado no access a arquivos na partição do sistema. Eu tenho um segundo disco rígido e ver resultados idênticos quando executado com essa modificação do registro na minha unidade C, como eu faço sem ele na unidade D.

Essa mudança leva time git status de 2,5 segundos para 0,7 segundos.

Você também pode querer seguir https://github.com/msysgit/git/pull/94 e https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b para verificar o trabalho adicional em andamento para problemas de velocidade no Windows .

Em uma extensão à resposta de Chris Dolan, usei a seguinte configuração alternativa de PS1. Basta adicionar o fragment de código ao seu ~ / .profile (no 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\] $ ' 

Isso mantém o benefício de um shell colorido e a exibição do nome atual do branch (se estiver em um repository do git), mas é significativamente mais rápido em minha máquina, de ~ 0.75s a 0.1s.

Baseado neste blog .

Parece que desinstalar completamente o Git, reiniciar (a cura clássica do Windows) e reinstalar o Git foi a cura. Eu também limpei todos os arquivos de configuração do bash que sobraram (eles foram criados manualmente). Tudo é rápido novamente.

Se por algum motivo a reinstalação não for possível (ou desejável), então eu definitivamente tentaria alterar a variável PS1 mencionada na resposta de Chris Dolan ; isso resultou em acelerações significativas em certas operações.

Eu resolvi meu problema de git lento no Win 7 x64, iniciando cmd.exe com “Executar como administrador”.

Eu vi uma melhoria decente, definindo core.preloadindex para true como recomendado aqui .

Eu sei que isso é velho, mas eu estava tendo o mesmo problema, tanto no Git Bash quanto no Git Gui. Ambos os programas funcionam bem, mas depois eles desaceleraram aleatoriamente para um rastreamento, e eu não consegui entender o porquê. Acontece que foi o Avast. O Avast fez com que coisas estranhas acontecessem a vários programas (incluindo programas que escrevo), então eu o desativei por um segundo, e com certeza, o Bash agora roda tão rápido quanto no Linux. Acabei de adicionar a pasta de arquivos do programa Git (C: \ Program Files \ Git) à lista de exclusão do Avast, e agora ela é executada tão rápido quanto no Linux.

E sim, eu percebo que o Anti-Virus não foi o problema no post original, mas vou colocar isso aqui, caso seja útil para alguém.

Como observado nas respostas de Chris Dolan e Wilbert, o PS1 te atrasa .

Em vez de desabilitar completamente (como sugerido por Dolan) ou usar o script oferecido por Wilbert, eu uso um “PS1 estúpido” que é muito mais rápido.

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

No meu cygwin, isso é mais rápido do que a resposta “fast_git_ps1” de Wilbert – 200ms vs. 400ms, então isso reduz um pouco sua lentidão imediata.

Não é tão sofisticado quanto __git_ps1 – por exemplo, ele não altera o prompt quando você clica no diretório .git, etc., mas para o uso diário normal é bom o suficiente e rápido.

Testado no git 1.7.9 (cygwin, mas deve funcionar em qualquer plataforma)

Você também pode ganhar um aumento de desempenho muito subseqüente alterando a seguinte configuração do git:

 git config --global status.submoduleSummary false 

Ao executar o comando simple git status no Window 7 x64, meu computador levou mais de 30 segundos para ser executado. Após esta opção ter sido definida, o comando é imediato.

Ativar o próprio rastreamento do Git como explicado na página a seguir me ajudou a encontrar a origem do problema, que pode ser diferente em sua instalação: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so- lento

Respostas combinadas:

  1. Wilbert – que informações include no 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}\] $ ' 

Resultado:

frolowr @ RWAMW36650 / c / projetos / elm-math-kids (master) $

Eu encontrei o mesmo problema executando o git para Windows (msysgit) no Windows 7 x64 como uma conta de usuário limitada por algum tempo. Pelo que li aqui e em outros lugares, o tema comum parece ser a falta de privilégios administrativos e / ou UAC. Como o UAC está desativado em meu sistema, a explicação de que ele está tentando gravar / excluir algo no diretório de arquivos do programa faz mais sentido para mim.

De qualquer forma, resolvi meu problema instalando a versão portátil do git 1.8 com o zipinstaller. Observe que eu tive que descompactar o arquivo de distribuição .7z e empacotá-lo como um zip para que o zipinstaller funcionasse. Eu também tive que adicionar manualmente esse diretório para o caminho do meu sistema.

O desempenho está bem agora. Embora esteja instalado no diretório Program Files (x86), para o qual não tenho permissions como usuário limitado, ele não parece sofrer do mesmo problema. Atribuo isso ao fato de que a versão portátil é um pouco mais conservadora no local em que escreve / exclui arquivos, o que provavelmente é o caso, ou na atualização de 1.7 para 1.8. Eu não vou tentar definir qual é o motivo, basta dizer que funciona muito melhor agora, incluindo o bash.

No meu caso, na verdade, era o antivírus Avast que levava ao git bash e até o Powershell se tornava muito lento.

Eu tentei primeiro desabilitar o Avast por 10 minutos para ver se ele melhorou a velocidade. Depois, adicionei todo o diretório de instalação do Git Bash como uma exceção no Avast, para Read, Write and Execute. No meu caso, isso foi C:\Program Files\Git\* .

Se você usar o Git do cmd, tente executá-lo no Git Bash. Em cmd, o git.exe é na verdade um wrapper que configura o ambiente correto toda vez que você o inicia, e só então inicia o git.exe real. Pode levar até o dobro do tempo necessário para fazer o que você deseja. E o Git Bash configura o ambiente apenas quando ele é iniciado.

Nada do acima foi capaz de me ajudar. No meu cenário, o problema estava se mostrando assim:

  • Qualquer comando ll era lento (demorava cerca de 3 segundos para ser executado)
  • Qualquer comando ll subseqüente foi executado instantaneamente, mas somente se dentro de 45 segundos do comando ls anterior .

Quando chegou a debugging com o Process Monitor , foi descoberto que, antes de cada comando, havia uma solicitação de DNS.

Então, assim que eu desabilitei meu firewall (Comodo no meu caso) e deixei o comando executar o problema acabou. E não está voltando quando o firewall foi ligado novamente. Com a primeira oportunidade, atualizarei essa resposta com mais detalhes sobre qual processo estava fazendo uma solicitação de DNS de bloqueio e qual era o destino.

BR, G

Apenas desligar o AMD Radeon Graphics (ou Intel Graphics) no Gerenciador de dispositivos me ajudou.

insira a descrição da imagem aqui

Eu encontrei a resposta aqui: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows# =

Além dessas outras respostas, tenho acelerado projetos com múltiplos submódulos usando a busca de submódulos paralelos (desde o git 2.8 no início de 2016).

Isso pode ser feito com git fetch --recurse-submodules -j8 e configurado com git config --global submodule.fetchJobs 8 , ou quantos núcleos você quiser / quiser usar.

Eu também tive problema com lentidão PS1 PSIT, embora por um longo tempo eu estava pensando que é um problema de tamanho de db (grande repo), e estava tentando vários git gc triks, e estavam procurando por outras razões, assim como você. No entanto, no meu caso, o problema foi esta linha:

 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 } 

Então, o que foi lento foi fazer o status do git para cada linha de status da linha de comando. Ai Foi algo que escrevi à mão. Eu vi que era problema quando eu tentei o

 export PS1='$' 

como mencionado em uma resposta aqui. Linha de comando foi rápida como um raio.

Agora estou usando isso:

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

A partir disso, assim https://stackoverflow.com/a/11975827/2492808 e funciona bem. Mais uma vez, tem a linha de comando rápida do git.

No meu caso, o atalho do git bash foi configurado para Start in:%HOMEDRIVE%%HOMEPATH% (você pode verificar isso clicando com o botão direito em git bash e selecionando properties). Esta foi a unidade de rede.

A solução é apontar para %HOME% . Se você não tem, você pode configurá-lo nas variables ​​de ambiente e agora o bas do git deve ser muito rápido.

Estou muito atrasado para a festa, eu sei …

… mas: um colega meu teve problemas com git no windows (7) git status checkout e add foram rápidos, mas git commit demorou.

Ainda estamos tentando encontrar a causa raiz disso, mas clonar o repository em uma nova pasta resolveu seu problema. Pensei em adicioná-lo aqui, caso alguém tenha o mesmo problema e ainda esteja procurando uma solução.