我喜欢在向上游推送提交之前检查它们，所以我总是在提交之前运行gitk(我喜欢一点可视化)。不过，我注意到，先提交代码，然后运行gitk要快得多。
较慢：
- [有未提交的更改]
gitk- 审查未提交的更改
速度快了一点：(还没有计时，但它似乎是即时的，而不是几秒钟的滞后)
- git提交
gitk- 查看上次提交
- 根据需要还原或修改
我的理解是git在创建提交时基本上运行diff。那么，为什么对未提交的代码进行区分要比提交和审查最后一次提交花费更长的时间呢？
我的理解是git在创建提交时基本上运行diff。
至少，这不是真的。提交时，Git只需按照原样归档当前索引。提交中没有差异；相反，它们是在每次实际查看提交时动态生成的。
因此，在某种程度上，你也有错误的想法。当您使用gitk查看最后一次提交时，gitk实际上会运行git diff来生成您所看到的内容，所以如果您不觉得那么慢，那么git diff根本就不慢。：)
如果生成当前工作树的diff很慢，那么我怀疑这更像是文件系统的问题。我从来没有发现它很慢，我甚至使用NFS。(所以我必须承认，我不太明白你的文件系统怎么会比这个慢得多。)
或者，它可能只是对缓慢的gitk进行位处理。我从来没有用过它来查看存储库的当前状态，通常更喜欢git status、git diff和/或git gui。(我确实使用gitk，但几乎只用于查看历史和/或历史提交。)
几个提示：
- 让
gitk在后台运行，而不是每次都重新启动它 - 检查运行
git diff本身是否与启动gitk一样慢 - 可以肯定的是，运行
git gc来优化存储库
EDIT：既然你已经提到你使用Windows7运行，那么应该提到的是，Linus在评论Git的设计时引用了他的话，他充分利用了Linux内核文件系统实现的知识来提高Git的速度。那么，将工作树与索引进行比较时速度较慢的原因很可能是Windows7的文件系统调用速度比Linux慢，和/或根本不喜欢Git使用文件系统的方式。
Git邮件列表上的这个线程似乎和你遇到的问题一样，只是更糟。它引用了这样一句话：
我认为简单的现实是Git是在假设的情况下编写的该统计数据很便宜，而Windows上的情况并非如此文件系统缓存对此似乎做得不太好。
SO上的这个答案提到了msysgit的补丁，它显著提高了Windows上的性能。