我很有兴趣阅读这张关于Mercurial的幻灯片，尤其是下面的幻灯片：
利用FS
- 避免寻道对性能至关重要
- 遍历顺序很重要
- 通过哈希排序意味着在工作目录，并降级为随机在副本上查找
- 按修改时间排序会降低到随时间的随机搜索
- 按路径名排序是稳定的头部运动基本上是单调的
(强调矿(
我从中得到的是：使用哈希(如SHA-1哈希(将对象存储在对象存储中的版本控制系统在读取文件时最终会比基于路径名的对象存储慢。这张幻灯片没有明确提到Git，也没有声称由于这个原因Git速度较慢，但这是我合乎逻辑的结论。
我对Mercurial一点也不了解，但从一点阅读中，我得到的印象是hg-reos使用了一个名为"清单"；以记录用于特定"文件"的文件的位置和散列ID；变更集"；(版本/提交(。我从wiki中注意到，清单中似乎确实包含了文件的路径。Git使用平面(ish(对象存储，其中所有对象(Blob、树和提交(都存储在同一目录中，提交指向树对象，树指向Blob和其他树，所有这些都用于为每个版本重建工作目录的状态。
因此，根据这张幻灯片中的声明；通过散列排序"；Git命令的读取速度应该比Mercurial清单系统慢。
问题是：这是否准确？Git和Mercurial之间的读取速度是否存在差异，这是由于对象存储的结构造成的？或者这本质上是Mercurial的营销？
问题是：这准确吗？
测量并找出答案。这是唯一知道的方法，尤其是在文件系统格式和存储技术发生变化的情况下。特别是，寻道时间与SSD无关(它们没有寻道操作(。在2005年左右，当这些系统被写入时，8GB的RAM和1TB的旋转媒体存储是一个相当大的系统。现在，拥有64GB RAM和半TB固态存储空间的手机是很正常的；a"；"大"；服务器计算机有高达1TB的RAM，十几个左右的SSD作为旋转介质的缓存前端，以及一组64个22TB的旋转介质驱动器，用于超过1 PB的磁盘存储。
Git也不将文件存储为文件，而是将其存储为对象。与此同时，Mercurial将文件存储为delta，但偶尔会认为delta链太长，并存储文件的新副本。Mercurial在其变更集数据库内部使用仅限扩展的文件格式，而Git将在有利可图的时候创建新的松散对象和新的包文件。Git现在还为包文件、多包索引文件、可选的提交图数据结构和位图创建索引，以及在2010年代和20世纪20年代发生的许多其他优化，早在那张幻灯片之后。