Git Bash 在 Windows 7 x64 上非常慢

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/4485059/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-09 19:59:03  来源:igfitidea点击:

Git Bash is extremely slow on Windows 7 x64

gitbashwindows-7msysgitmingw32

提问by Gemini14

I've been using Git on both Windows and Ubuntu during the development of a small project, frequently flipping back and forth between the two. The issue is that Git Bashconsistently becomes slow.

在开发一个小项目的过程中,我一直在 Windows 和 Ubuntu 上使用 Git,经常在两者之间来回切换。问题是Git Bash一直变慢。

When I say slow, I mean that running cdtakes anywhere from 8-25 seconds, running gitcommands take from 5-20 seconds, and lscan take up to 30 seconds sometimes. Needless to say, this is not fun, not to mention unproductive. I know Git is slower on Windows, but this is ridiculous.

当我说慢时,我的意思是运行cd需要 8-25 秒,运行git命令需要 5-20 秒,ls有时可能需要长达 30 秒。不用说,这不好玩,更不用说没有生产力了。我知道 Git 在 Windows 上速度较慢,但​​这很荒谬。

The one solution which has worked--temporarily--for me has been to disable my network connection (as suggested in this answer), start Git Bash, and then reconnect. Sometimes it continues to run quickly for days after doing that, but the performance always degrades eventually. I've trawled through the msysgit discussion group, Stack Overflow, msysgit issue list, etc. on and off for weeks, but I haven't been able to turn up solutions which work.

对我来说暂时有效的一种解决方案是禁用我的网络连接(如本答案中所建议的那样),启动 Git Bash,然后重新连接。有时它会在这样做后继续快速运行数天,但最终性能总是会下降。我已经断断续续地浏览了 msysgit 讨论组、堆栈溢出、msysgit 问题列表等数周,但我一直无法找到有效的解决方案。

So far, I've tried:

到目前为止,我已经尝试过:

  • Adding Git & project folders to the virus scanner's exclusion list
  • Disabling my virus scanner completely (Kaspersky IS 2011)
  • Ensuring that Outlook is not running (Outlook 2007)
  • Shutting down all other applications
  • Running Git Bash as administrator
  • Disabling network connection, starting Git Bash, and keeping connection disabled
  • Disabling network connection, starting Git Bash, re-enabling connection (works only occasionally)
  • Running git gc
  • And combinations of the above
  • 将 Git 和项目文件夹添加到病毒扫描程序的排除列表
  • 完全禁用我的病毒扫描程序(Kaspersky IS 2011)
  • 确保 Outlook 未运行(Outlook 2007)
  • 关闭所有其他应用程序
  • 以管理员身份运行 Git Bash
  • 禁用网络连接,启动 Git Bash,并保持连接禁用
  • 禁用网络连接,启动 Git Bash,重新启用连接(仅偶尔工作)
  • 跑步 git gc
  • 以及以上的组合

I did read that a couple of people had success disabling Bash completion, but ideally I'd like to keep that active. The version of msysgit is 1.7.3.1-preview20101002 & the OS is Windows 7 x64. Running the same things on Linux is, predictably, lightning fast. I would use Linux exclusively, but I need to run stuff in Windows, too (certain applications, testing, etc.).

我确实读到有几个人成功禁用 Bash 完成,但理想情况下我希望保持活跃。msysgit 的版本是 1.7.3.1-preview20101002 & 操作系统是 Windows 7 x64。可以预见的是,在 Linux 上运行相同的东西是闪电般的快。我会专门使用 Linux,但我也需要在 Windows 中运行东西(某些应用程序、测试等)。

Has anyone encountered a similar issue? If so, what was the underlying problem and what was the solution (if any)?

有没有人遇到过类似的问题?如果是这样,潜在的问题是什么,解决方案是什么(如果有的话)?

This extends beyond just the Git repositories, but just for reference, the repositories I've been using Git with have been pretty small: ~4-50 files maximum.

这不仅仅是 Git 存储库,但仅供参考,我一直在使用 Git 的存储库非常小:最多约 4-50 个文件。

采纳答案by Gemini14

It appears that completely uninstalling Git, restarting (the classic Windows cure), and reinstalling Git was the cure. I also wiped out all bash config files which were left over (they were manually created). Everything is fast again.

似乎完全卸载 Git、重新启动(经典的 Windows 解决方案)并重新安装 Git 是解决方案。我还清除了剩下的所有 bash 配置文件(它们是手动创建的)。一切又来得很快。

If for some reason reinstalling isn't possible (or desirable), then I would definitely try changing the PS1 variable referenced in Chris Dolan's answer; it resulted in significant speedups in certain operations.

如果由于某种原因无法(或不可取)重新安装,那么我肯定会尝试更改Chris Dolan 的回答中引用的 PS1 变量;它导致某些操作的显着加速。

回答by shoelzer

You can significantly speed up Git on Windows by running three commands to set some config options:

您可以通过运行三个命令来设置一些配置选项来显着加快 Windows 上的 Git:

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

Notes:

笔记:

  • core.preloadindexdoes filesystem operations in parallel to hide latency (update: enabled by default in Git 2.1)

  • core.fscachefixes UAC issues so you don't need to run Git as administrator (update: enabled by default in Git for Windows 2.8)

  • gc.autominimizes the number of files in .git/

  • core.preloadindex并行执行文件系统操作以隐藏延迟(更新:在 Git 2.1 中默认启用)

  • core.fscache修复了 UAC 问题,因此您无需以管理员身份运行 Git(更新:Git for Windows 2.8 默认启用)

  • gc.auto最小化 .git/ 中的文件数量

回答by Chris Dolan

Do you have Git information showing in your Bash prompt? If so, maybe you're inadvertently doing way too much work on every command. To test this theory try the following temporary change in Bash:

您的 Bash 提示中是否显示了 Git 信息?如果是这样,也许您无意中对每个命令都做了太多工作。要测试这个理论,请尝试在 Bash 中进行以下临时更改:

export PS1='$'

回答by Rob Johnson

My Windows home directory is on the network, and I suspected that Git Bash commands were looking there first. Sure enough, when I looked at $PATH, it listed /h/binfirst, where /his a share on a Windows file server, even though /h/bindoesn't exist.
I edited /etc/profileand commented out the export command that puts it first in $PATH:

我的 Windows 主目录在网络上,我怀疑 Git Bash 命令首先在那里查找。果然,当我查看时$PATH,它/h/bin首先列出/h了 Windows 文件服务器上的共享位置,即使/h/bin不存在。
我编辑/etc/profile并注释掉了将它放在首位的导出命令$PATH

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

This made my commands run much faster, probably because Git Bash is no longer looking across the network for the executables. My /etc/profilewas c:\Program Files (x86)\Git\etc\profile.

这使我的命令运行得更快,可能是因为 Git Bash 不再通过网络查找可执行文件。我的/etc/profilec:\Program Files (x86)\Git\etc\profile

回答by MichaelK

I found the network drive was the performance problem. HOMEwas pointing to a slow network share. I could not override HOMEDRIVEbut that is not a problem from what I have seen.

我发现网络驱动器是性能问题。HOME指向缓慢的网络共享。我无法覆盖,HOMEDRIVE但这不是我所看到的问题。

Set the environment variable by right clicking your computer on the desktop --> properties --> Advanced system settings --> Environment Variables Add to User variables section

通过在桌面上右键单击您的计算机来设置环境变量 --> 属性 --> 高级系统设置 --> 环境变量添加到用户变量部分

HOME=%USERPROFILE%

回答by Wilbert

In an extension to Chris Dolan's answer, I used the following alternative PS1setting. Simply add the code fragment to your ~/.profile (on Windows 7: C:/Users/USERNAME/.profile).

在 Chris Dolan 的回答的扩展中,我使用了以下替代PS1设置。只需将代码片段添加到您的 ~/.profile(在 Windows 7 上:C:/Users/USERNAME/.profile)。

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [] / p')"
}

PS1='\[3]0;$MSYSTEM:\w
PS1='3[33m\]\w \n\[3[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[3[00m\]# '
7 3[32m\]\u@\h \[3[33m\w$(fast_git_ps1)3[0m\] $ '

This retains the benefit of a colored shell and display of the current branch name (if in a Git repository), but it is significantly faster on my machine, from ~0.75 s to 0.1 s.

这保留了彩色外壳和显示当前分支名称的好处(如果在 Git 存储库中),但它在我的机器上明显更快,从 ~0.75 s 到 0.1 s。

This is based on this blog post.

这是基于此博客文章

回答by Jeff Lamb

While your problem might be network-based, I've personally sped up my local git statuscalls tenfold (7+ seconds down to 700 ms) by doing two modifications. This is on a 700 MB repository with 21,000 files and excessive numbers of large binary files.

虽然您的问题可能是基于网络的,但我个人git status通过进行两次修改将我的本地呼叫速度提高了十倍(7 秒以上降低到 700 毫秒)。这是在一个 700 MB 的存储库中,其中包含 21,000 个文件和过多的大型二进制文件。

One is enabling parallel index preloads. From a command prompt:

一种是启用并行索引预加载。从命令提示符:

git config core.preloadindex true
This changed time git statusfrom 7 seconds to 2.5 seconds.

git config core.preloadindex true
time git status从 7 秒更改为 2.5 秒。

Update!

The following is no longer necessary. A patch has fixed this as of mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
However, you must enable the fix by typing
git config core.fscache true

更新!

以下不再需要。自 mysysgit 1.9.4 起 ,补丁已修复此问题
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
但是,您必须通过键入来启用修复
git config core.fscache true

I also disabled the UAC and the "luafv" driver (reboot required). This disables a driver in Windows Vista, 7 and 8 that redirects programs trying to write to system locations and instead redirects those accesses to a user directory.

我还禁用了 UAC 和“luafv”驱动程序(需要重新启动)。这会禁用 Windows Vista、7 和 8 中的驱动程序,该驱动程序将尝试写入系统位置的程序重定向,而是将这些访问重定向到用户目录。

To see a discussion on how this affects Git performance, read here: https://code.google.com/p/msysgit/issues/detail?id=320

要查看有关这如何影响 Git 性能的讨论,请阅读此处:https: //code.google.com/p/msysgit/issues/detail?id=320

To disable this driver, in regedit, change the "start" key at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafvto 4 to disable the driver. Then, put UAC to its lowest setting, "never notify".

要禁用此驱动程序,请在 regedit 中将“开始”键更改HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv为 4 以禁用该驱动程序。然后,将 UAC 设置为最低设置,“从不通知”。

If the disabling of this driver makes you wary (it should), an alternative is running on a drive (or partition) different than your system partition. Apparently the driver only runs on file access on the system partition. I have a second hard drive and see identical results when run with this registry modification on my C drive as I do without it on the D drive.

如果禁用此驱动程序让您感到谨慎(它应该如此),则替代方法是在与您的系统分区不同的驱动器(或分区)上运行。显然,驱动程序仅在系统分区上的文件访问时运行。我有第二个硬盘驱动器,在 C 驱动器上使用此注册表修改运行时看到的结果与在 D 驱动器上没有它时一样。

This change takes time git statusfrom 2.5 seconds down to 0.7 seconds.

此更改需要time git status从 2.5 秒缩短到 0.7 秒。

You also might want to follow https://github.com/msysgit/git/pull/94and https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663bto check out what additional work is underway for speed issues in Windows.

您可能还想关注https://github.com/msysgit/git/pull/94https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b以查看针对 Windows 中的速度问题正在进行的其他工作.

回答by Chris Pawlukowsky

I solved my slow Git problem on Windows 7 x64 by starting cmd.exe with "Run as administrator".

我通过使用“以管理员身份运行”启动 cmd.exe 解决了我在 Windows 7 x64 上运行缓慢的 Git 问题。

回答by Andy

I saw a decent improvement by setting core.preloadindex to true as recommended here.

按照此处的建议将 core.preloadindex 设置为true,我看到了不错的改进。

回答by sinelaw

As noted in Chris Dolan's and Wilbert's answers, PS1 slows you down.

正如 Chris Dolan 和 Wilbert 的回答中所指出的,PS1 会减慢您的速度

Rather than completely disabling (as suggested by Dolan) or using the script offered by Wilbert, I use a "dumb PS1" that is much faster.

我没有完全禁用(如 Dolan 建议的那样)或使用 Wilbert 提供的脚本,而是使用速度更快的“哑PS1”。

It uses (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null:

它使用(git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null

##代码##

On my Cygwin, this is faster than Wilbert's "fast_Git_PS1" answer- 200 ms vs. 400 ms, so it shaves off a bit of your prompt sluggishness.

在我的 Cygwin 上,这比Wilbert 的“fast_Git_PS1”答案要快- 200 毫秒与 400 毫秒,因此它减少了您的提示迟钝。

It isn't as sophisticated as __git_ps1- for example it doesn't change the prompt when you cd into the .git directory, etc. but for normal everyday use it's good enough and fast.

它没有那么复杂__git_ps1- 例如,当您 cd 进入 .git 目录等时,它不会更改提示,但对于正常的日常使用,它已经足够好且速度快了。

This was tested on Git 1.7.9 (Cygwin, but it should work on any platform).

这是在 Git 1.7.9(Cygwin,但它应该适用于任何平台)上测试的。