Git Bash очень медленно работает на Windows 7 x64

Question

Я использовал Git на Windows и Ubuntu во время разработки небольшого проекта, часто переключаясь между ними. Проблема в том, что Git Bash постоянно работает медленно.

Когда я говорю медленно, я имею в виду, что бег cd занимает от 8 до 25 секунд, работает git Команды занимают от 5-20 секунд, и ls иногда может занять до 30 секунд. Излишне говорить, что это не весело, не говоря уже о непродуктивности. Я знаю, что Git медленнее в Windows, но это смешно.

Единственное решение, которое сработало - временно - для меня, состояло в том, чтобы отключить сетевое подключение (как предложено в этом ответе), запустить Git Bash, а затем повторно подключиться. Иногда он продолжает работать быстро в течение нескольких дней после этого, но производительность всегда падает в конце концов. Я пролистал дискуссионную группу msysgit, переполнение стека, список проблем msysgit и т. Д. В течение нескольких недель, но я не смог найти решения, которые работают.

Пока что я пробовал:

• Добавление папок Git & project в список исключений антивирусного сканера
• Полное отключение моего антивирусного сканера (Kaspersky IS 2011)
• Обеспечение того, что Outlook не работает (Outlook 2007)
• Завершение работы всех других приложений
• Запуск Git Bash от имени администратора
• Отключение сетевого подключения, запуск Git Bash и сохранение соединения отключенным
• Отключение сетевого подключения, запуск Git Bash, повторное включение подключения (работает только изредка)
• Бег git gc
• И комбинации вышеперечисленного

Я читал, что несколько человек успешно отключили завершение Bash, но в идеале я хотел бы сохранить это активным. Версия msysgit - 1.7.3.1-preview20101002, операционная система - Windows 7 x64. Как и ожидалось, запуск одних и тех же вещей в Linux происходит молниеносно. Я бы использовал исключительно Linux, но мне также нужно запускать что-то в Windows (определенные приложения, тестирование и т. Д.).

Кто-нибудь сталкивался с подобной проблемой? Если да, то какова была основная проблема и каково ее решение (если есть)?

Это распространяется не только на репозитории Git, но просто для справки, репозитории, с которыми я работал, были довольно маленькими: максимум 4-50 файлов.

Answer 1

Похоже, что полностью удалить Git, перезапустить (классическое лечение Windows) и переустановить Git. Я также уничтожил все файлы конфигурации bash, которые остались (они были созданы вручную). Все снова быстро.

Если по какой-либо причине переустановка невозможна (или нежелательна), то я бы определенно попытался изменить переменную PS1, указанную в ответе Криса Долана; это привело к значительному ускорению в определенных операциях.

Answer 2

Вы можете значительно ускорить Git в Windows, запустив три команды для настройки некоторых параметров конфигурации:

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

Заметки:

• core.preloadindex выполняет операции файловой системы параллельно, чтобы скрыть задержку (обновление: включено в Git 2.1 по умолчанию)

• core.fscache устраняет проблемы с UAC, поэтому вам не нужно запускать Git от имени администратора (обновление: по умолчанию включено в Git для Windows 2.8)

• gc.auto минимизирует количество файлов в.git/

Answer 3

У вас есть информация о Git, отображаемая в приглашении Bash? Если это так, возможно, вы случайно выполняете слишком много работы над каждой командой. Чтобы проверить эту теорию, попробуйте следующее временное изменение в Bash:

export PS1='$'

Answer 4

Мой домашний каталог Windows находится в сети, и я подозревал, что команды Git Bash искали там в первую очередь. Конечно, когда я смотрел на $PATH, он сначала перечислял / h / bin, где / h - это общий ресурс на файловом сервере Windows, даже если / h / bin не существует. Я отредактировал / etc / profile и прокомментировал команду экспорта, которая ставит ее первой в $PATH:

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

Это заставило мои команды работать намного быстрее, вероятно, потому что Git Bash больше не ищет в сети исполняемые файлы. Мой / etc / profile был c:\Program Files (x86)\Git\etc\profile.

Answer 5

Я обнаружил, что сетевой диск был проблемой производительности. HOME указывал на медленный сетевой ресурс. Я не мог переопределить HOMEDRIVE но это не проблема из того, что я видел.

Задайте переменную среды, щелкнув правой кнопкой мыши компьютер на рабочем столе -> свойства -> Дополнительные параметры системы -> Переменные среды Добавить в раздел пользовательских переменных

HOME=%USERPROFILE%

Answer 6

В продолжение ответа Криса Долана я использовал следующую альтернативу PS1 установка. Просто добавьте фрагмент кода в ваш ~/.profile (в 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\]
$ '

Это сохраняет преимущество цветной оболочки и отображения текущего имени ветки (если в Git-репозитории), но это значительно быстрее на моей машине, от ~0,75 с до 0,1 с.

Это основано на этом сообщении в блоге.

Answer 7

Хотя ваша проблема может быть связана с сетью, я лично ускорил git status вызывает в десять раз (7+ секунд до 700 мс), выполнив две модификации. Это хранилище объемом 700 МБ с 21 000 файлов и избыточным количеством больших двоичных файлов.

Один включает параллельные предварительные загрузки индекса. Из командной строки:

git config core.preloadindex true
Это изменилось time git status от 7 секунд до 2,5 секунд.

Обновить!

Следующее больше не нужно. Патч исправил это с mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Тем не менее, вы должны включить исправление, набрав
git config core.fscache true

Я также отключил UAC и драйвер "luafv" (требуется перезагрузка). Это отключает драйвер в Windows Vista, 7 и 8, который перенаправляет программы, пытающиеся выполнить запись в системные расположения, и вместо этого перенаправляет эти обращения в пользовательский каталог.

Чтобы узнать, как это влияет на производительность Git, прочитайте здесь: https://code.google.com/p/msysgit/issues/detail?id=320

Чтобы отключить этот драйвер, в regedit измените ключ "Пуск" в HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv до 4, чтобы отключить драйвер. Затем установите UAC на самое низкое значение, "никогда не уведомлять".

Если отключение этого драйвера заставляет вас насторожиться (так и должно быть), альтернатива запускается на диске (или разделе), отличном от системного раздела. Видимо, драйвер работает только при доступе к файлу в системном разделе. У меня есть второй жесткий диск, и я вижу такие же результаты при запуске с этой модификацией реестра на моем диске C, как и без него на диске D.

Это изменение требует time git status от 2,5 секунд до 0,7 секунд.

Возможно, вы также захотите подписаться на https://github.com/msysgit/git/pull/94 и https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b чтобы узнать, какая дополнительная работа ведется для проблем со скоростью в Windows,

Answer 8

Я решил проблему с медленным Git в Windows 7 x64, запустив cmd.exe с "Запуск от имени администратора".

Answer 9

Я увидел приличное улучшение, установив для core.preloadindex значение true, как рекомендовано здесь.

Answer 10

Вы также можете значительно повысить производительность, изменив следующую конфигурацию Git:

git config --global status.submoduleSummary false

Когда работает простой git status Команда на Windows 7 x64, мой компьютер работал более 30 секунд. После того, как эта опция была определена, команда является немедленной.

Активация собственной трассировки Git, как объяснялось на следующей странице, помогла мне найти источник проблемы, которая может отличаться в вашей установке: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

Answer 11

Помогло только отключение AMD Radeon Graphics (или Intel Graphics) в диспетчере устройств.

Я нашел ответ здесь: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows

Answer 12

В дополнение к этим другим ответам я ускорил проекты с несколькими подмодулями, используя параллельную выборку подмодулей (начиная с Git 2.8 в начале 2016 года).

Это может быть сделано с git fetch --recurse-submodules -j8 и установить с git config --global submodule.fetchJobs 8или сколько ядер вы используете / хотите использовать.

Answer 13

Как отмечается в ответах Криса Долана и Уилберта, PS1 замедляет вас.

Вместо того, чтобы полностью отключить (как предложено Доланом) или использовать сценарий, предложенный Уилбертом, я использую "тупую PS1", которая намного быстрее.

Оно использует (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\]# '

На моем Cygwin это быстрее, чем ответ "fast_Git_PS1" Уилберта - 200 мс против 400 мс, так что он немного сбивает вашу медлительность.

Это не так сложно, как __git_ps1 - например, он не меняет приглашение при переходе в каталог.git и т. д., но для обычного повседневного использования это достаточно хорошо и быстро.

Это было проверено на Git 1.7.9 (Cygwin, но он должен работать на любой платформе).

Answer 14

У меня была та же проблема, как в Git Bash, так и в Git GUI. Обе программы хорошо работают, но затем они случайно замедлились до ползучести, и я не мог понять, почему.

Как оказалось, это был Аваст. Avast вызывал странные вещи с различными программами (включая программы, которые я пишу), поэтому я отключил его на секунду, и, конечно же, Bash теперь работает так же быстро, как и в Linux. Я только что добавил папку с файлами программы Git (C:\Program Files\Git) в список исключений Avast, и теперь он работает так же быстро, как и в Linux.

И да, я понимаю, что антивирусное программное обеспечение не было проблемой в оригинальном посте, но я просто помещу это здесь на случай, если оно кому-нибудь пригодится.

Answer 15

В моем случае ярлык Git Bash был установлен на Start in:%HOMEDRIVE%%HOMEPATH% (Вы можете проверить это, щелкнув правой кнопкой мыши Git Bash и выбрав свойства). Это был сетевой диск.

Решение состоит в том, чтобы указать %HOME%, Если у вас его нет, вы можете установить его в переменных окружения, и теперь Git Bash должен работать молниеносно.

Answer 16

Комбинированные ответы:

1. Уилберта - какую информацию включить в PS1
2. Sinelaw's - (<branch_name>) или же (<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://stackru.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackru.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackru.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}\] $ '

Результат:

Answer 17

Я сталкивался с той же проблемой при запуске Git для Windows (msysgit) на Windows 7 x64 в качестве учетной записи ограниченного пользователя в течение достаточно долгого времени.

Из того, что я читал здесь и в других местах, общей темой, похоже, является отсутствие административных привилегий и / или UAC. Поскольку UAC в моей системе отключен, объяснение того, что оно пытается что-то записать / удалить в каталоге программных файлов, имеет для меня самый смысл.

В любом случае, я решил свою проблему, установив переносную версию Git 1.8 с zipinstaller. Обратите внимание, что для работы zipinstaller мне пришлось распаковать дистрибутивный файл.7z и упаковать его как ZIP-файл. Мне также пришлось вручную добавить этот каталог в мой системный путь.

Производительность в порядке сейчас. Даже если он установлен в Program Files (x86) каталог, для которого у меня нет разрешений как для ограниченного пользователя, похоже, он не страдает от той же проблемы.

Я приписываю это либо факту, что портативная версия немного более консервативна в том, что она пишет / удаляет файлы, что, вероятно, имеет место, либо обновлению с 1.7 до 1.8. Я не собираюсь пытаться определить причину, достаточно сказать, что теперь она работает намного лучше, включая Bash.

Answer 18

Если вы используете Git из cmd, попробуйте запустить его из Git Bash. В cmd git.exe на самом деле является оберткой, которая устанавливает правильную среду каждый раз, когда вы ее запускаете, и только после этого запускает настоящий git.exe. Это может занять вдвое больше времени, чем требуется, чтобы просто делать то, что вы хотите. А Git Bash настраивает среду только тогда, когда она запускается.

Answer 19

В моем случае это был антивирус Avast, который привел к появлению Git Bash, и даже PowerShell стал очень медленным.

Сначала я попытался отключить Avast на 10 минут, чтобы увидеть, улучшил ли он скорость и сделал ли это. После этого я добавил весь каталог установки Git Bash в качестве исключения в Avast для чтения, записи и выполнения. В моем случае это было C:\Program Files\Git\*,

Answer 20

У меня была похожая ситуация, и моя проблема была связана с Active Directory и сидением за vpn.

Нашел это золото, проработав так полгода: http://bjg.io/guide/cygwin-ad/

Все, что вам в основном нужно, это отключить dbв /etc/nsswitch.conf(вы можете найти его в своем каталоге git) из passwdа также groupраздел, поэтому файл выглядит так:

      # Begin /etc/nsswitch.conf
passwd: files
group: files
db_enum: cache builtin
db_home: cygwin desc
db_shell: cygwin desc
db_gecos: cygwin desc
# End /etc/nsswitch.conf

а затем один раз обновите локальный пароль и настройки группы:

      $ mkpasswd -l -c > /etc/passwd
$ mkgroup -l -c > /etc/group

Answer 21

Ничто из перечисленного не могло мне помочь. В моем сценарии проблема проявлялась так:

• любой ll команда была медленной (выполнение заняло около 3 секунд)
• Любое последующее ll Команда была выполнена мгновенно, но только если в течение 45 секунд после предыдущей команды ls.

Когда дело дошло до отладки с помощью Process Monitor, выяснилось, что перед каждой командой был DNS-запрос.

Поэтому, как только я отключил брандмауэр (в моем случае Comodo) и позволил команде выполнить команду, проблема исчезла. И он не возвращается обратно, когда брандмауэр был снова включен. При первой же возможности я обновлю этот ответ с более подробной информацией о том, какой процесс выполнял блокирующий DNS-запрос и какова была цель.

BR, G

Answer 22

У моего коллеги были проблемы с Git на Windows (7) git statuscheckout а также add были быстрыми, но git commit взял возраст.

Мы все еще пытаемся найти причину этого, но клонирование хранилища в новую папку решило его проблему.

Answer 23

Как многие говорили, это связано с stash являясь сценарием оболочки в Windows, но начиная с Git 2.18.0, установщик Windows имеет опцию для экспериментальной функции гораздо более быстрой (~90%) встроенной версии stash - https://github.com/git-for-windows/build-extra/pull/203.

Answer 24

Я нашел два полезных метода диагностики из вики git repo:https://github.com/git-for-windows/git/wiki/Diagnosing- Performance-issues

По сути, добавлениеset -xдо вершины<git install home>/etc/profile, будет отображать фактические выполненные команды оболочки. Таким образом, вы можете узнать, какая команда вызывает задержку быстрого выполнения.

Но в моем случае это были в основном сетевые операции. я добавилGIT_TRACE=1 к моей команде git, чтобы она распечатывала выполняемые ею команды sub git.

В моем случае я узналgit-credential-manager getвыполнялся несколько раз, и каждый вызов ожидает несколько секунд. Итак, погуглив, я попробовалgit config --system --unset credential.helperв режиме администратора. Sourcetree теперь работает быстро, хотя мне нужно каждый раз повторно вводить учетные данные в git bash.

Некоторые подозревают, что это было вызвано антивирусом, но сейчас я не могу это проверить.https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/786

Answer 25

У меня также была проблема с медлительностью git PS1, хотя долгое время я думал, что это проблема размера базы данных (большой репозиторий), и пробовал разные git gc трюки, и искали другие причины, как и вы. Однако, в моем случае, проблема была в этой строке:

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
}

Делать git status для каждой командной строки строка состояния была медленной. Уч. Это было то, что я написал от руки. Я увидел, что это проблема, когда я попробовал

export PS1='$'

как упомянуто в одном ответе здесь. Командная строка была молниеносной.

Теперь я использую это:

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

Из стека переполнения пост строки PS1 с git текущей веткой и цветами, и все работает отлично. Опять быстрая командная строка Git.