太长不看：
- 扫盘建立快照不够高效，占比 10%
- 网络条件拉跨，占比 10-100%（假如你家网速正常就 10%，不正常直接断了，影响算 100% 是没问题吧
） - 同步有锁，必须交替进行，占比 30%
- web 上传对小文件极不友好，占比 50%
关于一些前置的讨论可以看看 Issue #12246 · siyuan-note/siyuan ，我在这里研究了下 obsidian 的 livesync 插件与思源同步机制的差异，试图搞清楚，为啥都能使用 S3 作为同步中介，livesync 可以做到实时同步，而思源则有明显的卡顿感。
一个反直觉的观点是，思源的快照机制并不慢，至少不是同步慢的最主要问题。以下是测试出来的快照建立时间于同步时间之间的差异：
- 日记编辑 0.75s，未同步
- 主题更新（22 个文件，2m 数据量）0.86s，同步时间 3s
- 安装插件（650 个文件，20m 数据量）3.36s，同步时间 94s
- 删除插件（删除 650 个文件，20mb 数据）0.86s，同步时间 14s
以上都是先建立快照，再进行同步的操作，换而言之，同步的时间已经是去除快照建立的时间了，但是还是可以看出相对于快照操作是很慢的。
因此同步慢的的最大根源就是同步加锁……而已吗？
直到今天之前，我都是这个观点，但我忽然想到，同步加锁只是会影响到另一端同步并下载云端内容的速度，理论上不会影响到我这一端上传的速度，或许还要严格评估一下 web io 对于同步速度的影响。因此我直接在本地搭建了一个 docker minio，新开了一个库作为测试。我同时把我主笔记库的数据复制过来了，总共是 800m 的大小，6500 个文件。
我阅读了 dejavu 的代码，发现它里面有对同时上传文件数的限制。我合理的怀疑这就是问题的根源。于是，我拉到本地，进行修改，将同时上传、下载文件数的限制，也是 NewPoolWithFunc 的 poolSize 全拉高了 10 倍，重新打包思源的 kernel，进行测试。以上所有操作都是基于思源是个开源软件，所有，哎，就是能改着玩！
在我进行修改之前，使用本地的 minio 进行全库上传的耗时是 440s，那么，你觉得我修改后的耗时是多少呢？
还是 436s！
这少掉的 4s，完全可以被认为就是一个误差而已，因此可以说，dejavu 里对同时上传文件大小的限制，根本就不是同步慢的原因。
我尝试绕过思源，直接通过 minio 的 webui 上传，时间相差无几。
接着，我做了另一种尝试，使用 restic 进行备份，然后直接通过 webui 上传。备份同样的内容，思源的同步机制总共生成了 13,062 个文件，259 个文件夹，而 restic 则是 48 个文件，261 个文件夹。
最后，restic 的上传时间为 10s。
在查看日志中发现，minio 的同时上传速度哪怕在本地也只能做到每秒 40 左右的文件。
作为测试，我尝试使用官方的上传机制，这次就更慢了，每秒只能上传 16 个文件。而且甚至因为同时上传等待时间过长，还给我返回了 time out 报错。
因此，问题的根源似乎很清楚了：思源扫盘建立快照当然可以进步，但进步空间不大。改善云端同步协作机制、实现无锁同步，以及改变思源的快照分片机制，才是根本解决方案。
那么，古尔丹，代价是什么呢？
代价就是，从此思源的增量下载能力可能大大减弱，可能你下载一个快照，就得把整个库下载回来，因为现在一个数据分块对应了多个实际的文件，你只能一起下载回来再拆分。
这里，我就不得不感慨，省空间换时间，还是省时间换空间，依然、并且永远，是一个值得考虑的问题啊。
