使用文件大小和修改时间（而非文件内容）作为判断词库是否修改的依据，从而提升 rime 启动速度

[t123yh]

Pull request

Feature

即使在词库已经 build 完成的状态下，启动 rime 仍需耗费较长时间，尤其是在树莓派等低性能设备上。我使用 rime-ice 配置，在词库已经 build 完成的情况下，再次启动 rime-api-console 程序，并在启动时对其进行 Profile 分析，可以得到如下结果：

由图可见，最耗费时间的函数是 compute_dict_file_checksum 函数。究其原因，rime engine 每次启动时，DictCompiler 会检查词库是否变化，如果词库发生变化则需重新 build 词库。目前使用的检测方法，是对词库源文件做 crc32 哈希操作，并将计算好的哈希值存入数据库。由于此方法需要完整读取词库文件内容，如果词库的体积较大 且设备的 IO 性能较差，rime 的启动就会变得非常慢。

以下是在我的 Ryzen 7 5700G 台式机上，使用 Debug 模式编译的 rime-api-console 的启动速度：

可以看到，rime-api-console 使用了 5.6 秒才进入可使用的状态。当然，如果用 Release 模式，性能会有所提升，但在 checksum 上花费大量时间的事实仍然成立。

我提交的 Pull Request 将“文件是否修改”的判断方法进行了调整，改为读取“文件大小+文件修改时间”并进行哈希。这样，rime 无需读取完整的词库也可以启动。

以下是使用同样的配置，应用我的修改后，rime-api-console 的启动速度。可以看到，只花费了 0.13 秒，相比原来提升了 30 倍。

运行 Profile，也提示瓶颈不再是 checksum 的计算。

Unit test

• Done

Manual test

• Done

Code Review

1. Unit and manual test pass
2. GitHub Action CI pass
3. At least one contributor reviews and votes
4. Can be merged clean without conflicts
5. PR will be merged by rebase upstream base

Additional Info

[jimmy54]

api提供快速启动模式。接口是RimeStartMaintenance。供参考。

[WhiredPlanck]

@t123yh 你可以看看这个提交：9f88c4c ，慢的原因之一是原先将文件内容读取为字节的方式就不是最佳实践，istreambuf_iterator 本来就是比较慢的，改成 stringstream 使用 rdbuf 后时间至少可以砍一半。

另外我不推荐这种判断方式，我已经实践过了。使用校验和来验证文件内容是否更改是比较准确的方法。文件大小和修改时间本身不属于文件的本源属性，容易受文件系统/操作系统不同带来的影响。