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, но просто для справки, репозитории, с которыми я использовал Git, были довольно маленькими: Максимум ~ 4-50 файлов.

Answer 1

Вы можете значительно ускорить 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 2

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

export PS1='$'

Answer 3

Мой домашний каталог 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 4

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

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

HOME=%USERPROFILE%

Answer 5

Хотя ваша проблема может быть связана с сетью, я лично ускорил свои локальные 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 измените ключ «start» на 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 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, перезапустить (классическое лечение Windows) и переустановить Git.Я также уничтожил все файлы конфигурации bash, которые остались (они были созданы вручную).Все снова быстро.

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

Answer 8

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

Answer 9

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

Answer 10

Как отмечалось в ответах Криса Долана и Уилберта, 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, но должно работать на любой платформе).