VisualStudioTeamServices（VSTS）承载了世界上最大的Git仓库：Windows源代码。保持云中可用代码的主要副本并使其成为高性能同时被超过个用户同时更新是一个巨大的成就，但只有工程师可以在他们的机器上使用核心Git客户端才有用。我们通过构建GVFS来实现这一点。
Windows存储库比任何其他Git存储库大几个数量级，这暴露了我们需要修复的核心Git中的一些性能问题，以使其能够与我们在Microsoft看到的大型存储库一起工作。由于Git是开源的，我们正在通过贡献这些修改来改进所有用户的Git。
回顾一下我们在年建成的项目，以及我们到底有多远，我想分享一下我们在过去一年中与Git社区合作过的一些我最喜欢的补丁的细节。
指数
该Git的指数是在当前的所有文件，并基于预期目标散列表的当前的暂存区。许多Git操作在执行所请求的操作之前将此索引加载到内存中。我们发现了几种加速索引交互的方法。
该索引是路径的有序列表。在每个索引负载上，Git检查确定列表仍然是有序的。通过跳过这个检查，我们可以加快18％的指数负荷。索引重建时，路径按正确的顺序写入。Git检查插入时是否有重复项，但是任何重复项都会连续出现。通过在进行二分查找之前检查最后一个条目，我们加快索引写入达20％。我们也减少了Git放弃和重新加载索引的频率。
我们还贡献了微观优化，以加速每个读取或写入索引，包括在计算合并和使用堆栈而不是堆分配时使用散列表而不是列表。
状态和签出
两个常用的Git命令是status和checkout。status检查工作目录的状态，以查看与当前HEAD不同的内容，同时checkout更新工作目录以匹配新的目录HEAD。这些操作经常被调用，但是在处理大型库时也是非常昂贵的。
许多工具，如VisualStudio团队资源管理器中，使用status到目前的变化可用来提交名单。许多项目都有大型的目录充满了status由于.gitignore文件而被忽略的构建工件。团队资源管理器使用特殊的标志来status显示这些被忽略的文件，但这可能是一个比重要的文件更大的列表。我们添加了新的标志来status使这个调用更快，现在其他工具也可以使用这些选项。在我们查看代码的同时，我们找到了提高git状态性能的方法-高达50％。
即使有了这些加速，我们仍然需要走文件系统来查找写入文件的当前状态。至少，我们确实需要。我们添加了一个文件系统监视器插件，并git提供git一个外部命令，显示文件系统更改的快照。虽然我们专注于提供与GVFS的集成，但也可以使用Watchman等工具。
缩略语
许多Git命令以简化的形式呈现对象哈希以便于人们更容易地阅读。这些缩写需要足够长以唯一地标识存储库中的单个对象。对于大量回购，计算缩写成为常见命令成本的重要部分。旧算法通过遍历所有以缩写哈希开始的对象来测试一个猜测的缩写长度，然后将长度增加1，直到只剩下一个对象。新算法通过对最接近的匹配执行有效的二进制搜索并计算公共前缀长度来找到正确的长度。这种改变gitlog--oneline在Linux存储库上加快了5％的命令速度。
Git以两种方式存储对象：包文件和松散对象。松散对象作为每对象一个对象存储在对象散列的前两个十六进制数字的.git/objects/??目录中??。当GVFS按需下载对象时，会将其放置为一个松散的对象。在Git自动重新包装成包装文件之前，大多数存储库没有很多松散对象，但是在GVFS情况下，存储库可能包含数以百万计的松散对象。在计算缩写时，Git创建一个内存缓存，列出每个目录中的所有松散对象。创建该列表时，通过调用通用的字符串格式方法来附加字符串来创建字符串列表。在某些情况下，这占用了12％的CPU时间。用一个简单的附加方法替换这个很容易取得轻松的成绩。
刚刚开始
这些并不是我们在年所做的唯一改进。您可以阅读以前的文章以了解更多信息：
GitforWindows2.11中的新增功能在GVFS之外优化Git微软在Git上做了一个很大的赌注，使其成为由VSTS托管的微软项目的主要版本控制系统。我们增加了对Git的更好的投资，并将在未来的几个月和几年中继续取得一些重大进展-这要感谢Git社区的每个人都非常愿意与我们合作，帮助我们获得这些补丁，贡献回上游。
转载请注明：http://www.0431gb208.com/sjszjzl/2425.html
