关于 - 小巧快速
小巧快速
Git 速度很快。 使用 Git,几乎所有操作都在本地执行,这使其在必须不断与某处服务器通信的集中式系统上具有巨大的速度优势。
Git 的构建是为了在 Linux 内核上工作,这意味着它从一开始就必须有效地处理大型存储库。 Git 是用 C 语言编写的,减少了与更高级语言相关的运行时的开销。 速度和性能从一开始就是 Git 的主要设计目标。
基准测试
让我们看看常见操作与 Subversion 的比较,Subversion 是一种常见的集中式版本控制系统,类似于 CVS 或 Perforce。 越小越快。
为了进行测试,在同一可用区中设置了大型 AWS 实例。 Git 和 SVN 都安装在两台机器上,Ruby 存储库被复制到 Git 和 SVN 服务器,并在两者上执行常见操作。
在某些情况下,这些命令并不完全匹配。 在这里,尝试匹配最低公分母。 例如,“commit” 测试还包括 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 倍 |
差异 Tags | 比较两个标签(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 倍 |
Blame | 单个文件的行注释(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 也具有项目整个历史记录中每个文件的每个版本。 这说明了它在客户端压缩和存储数据方面的效率。