关于 - 小巧快速
小巧快速
Git 速度很快。使用 Git,几乎所有操作都在本地执行,这使得它在需要不断与服务器通信的集中式系统上具有巨大的速度优势。
Git 是为 Linux 内核而设计的,这意味着它从一开始就必须有效处理大型仓库。Git 用 C 语言编写,减少了与高级语言相关的运行时开销。速度和性能从一开始就是 Git 的主要设计目标。
基准测试
让我们看看常见操作与 Subversion 的对比,Subversion 是一种类似于 CVS 或 Perforce 的常见集中式版本控制系统。越小越快。
为了测试,在相同的可用区内设置了大型 AWS 实例。Git 和 SVN 都安装在两台机器上,Ruby 仓库被复制到 Git 和 SVN 服务器上,并在两者上执行了常见操作。
在某些情况下,命令不完全匹配。这里尝试以最小公分母为准。例如,'提交'测试也包括 Git 的推送时间,尽管大多数情况下您不会在提交后立即推送到服务器,因为在 SVN 中这两个命令无法分开。
所有这些时间都以秒为单位。
操作 | Git | SVN | ||
---|---|---|---|---|
提交文件 (A) | 添加、提交并推送 113 个修改过的文件 (2164+,2259-) | 0.64 | 2.60 | 4 倍 |
提交图像 (B) | 添加、提交并推送一千张 1 KB 图像 | 1.53 | 24.70 | 16 倍 |
当前差异 | 将 187 个更改的文件 (1664+,4859-) 与上次提交进行差异对比 | 0.25 | 1.09 | 4 倍 |
最近差异 | 与前 4 次提交进行差异对比 (269 个更改/3609+,6898-) | 0.25 | 3.99 | 16 倍 |
标签差异 | 将两个标签 (v1.9.1.0/v1.9.3.0) 进行差异对比 | 1.17 | 83.57 | 71 倍 |
日志 (50) | 最近 50 次提交的日志 (19 KB 输出) | 0.01 | 0.38 | 31 倍 |
日志 (全部) | 所有提交的日志 (26,056 次提交 – 9.4 MB 输出) | 0.52 | 169.20 | 325 倍 |
日志 (文件) | 单个文件 (array.c – 483 个修订版) 的历史日志 | 0.60 | 82.84 | 138 倍 |
更新 | 提交 A 场景的拉取 (113 个文件更改,2164+,2259-) | 0.90 | 2.82 | 3 倍 |
追溯 | 单个文件 (array.c) 的行注释 | 1.91 | 3.04 | 1 倍 |
请注意,这对于 SVN 来说是最佳情况——服务器没有负载,并且与客户端机器有千兆位连接。如果连接速度较慢,几乎所有这些时间对于 SVN 来说会更糟,而许多 Git 的时间则不会受到影响。
显然,在许多这些常见的版本控制操作中,即使在 SVN 的理想条件下,Git 也比 SVN 快一到两个数量级。
Git 速度较慢的一个地方是初始克隆操作。在这里,Git 下载的是整个历史记录,而不仅仅是最新版本。如上图所示,对于只执行一次的操作来说,这并没有慢很多。
操作 | Git* | Git | SVN | |
---|---|---|---|---|
克隆 | Git 中的克隆和浅克隆(*) 与 SVN 中的检出对比 | 21.0 | 107.5 | 14.0 |
大小 (MB) | 克隆/检出后客户端总数据和文件大小 (MB) | 181.0 | 132.0 |
同样有趣的是,尽管 Git 拥有项目整个历史中每个文件的所有版本,但客户端数据的大小却非常相似。这说明了它在客户端压缩和存储数据的效率有多高。