Lib.rs

待办事项

• 将下载次数纳入报告中
• 让东西更美观、更直观 - 这样我们就可以再次尝试回归 :D
• 看看为什么 RipGrep 没有收到任何建议
• 更多报告 - 目前忽略了上下文收集以查看花费多少时间在哪里。

可能的改进

• 如果我们知道匹配的文件位于顶级，则建议使用 'top-level' globs，如 /README.md。否则，模式 README.md 实际上会匹配 */README.md。
• 在包含和排除中计算否定模式。后者似乎不起作用，如果没有人在使用它们，Cargo 可以使其正常工作或正确拒绝它们。也许。也许首先创建一个问题并看看他们的看法。
• 在块下载超时时，不要重新启动，而是从上次停止的地方继续下载
• 弹性：防止 ThreadPanics - 它们防止程序关闭
  • Futures 有一个包装器来捕获恐慌，尽管我们还没有使用它。恐慌只会使恐慌的 future 停止，而不会使整个程序停止。
• 在 Ctrl+C 时优雅地关闭
  • 当前实现依赖于数据库来处理中止写入，因此没有问题。然而，拥有一个表现良好的程序会更好。
• Git 正在减慢报告生成，因为将它们发送到 Git 并创建对象很慢。我们可能可以通过创建自己的松散对象并将这些发送到聚合器来将其多线程化，该聚合器将这些对象放入索引中。这仅在第一次报告生成时很有趣，因此可能不值得。
• 让 criner 的每个子部分使用自己的错误类型，这些错误类型在 crate 级别错误中聚合。这样，单个错误会更小。
• 单独解析 CSV 文件并索引行和字段 - 从那里动态构建一切，而无需分配和复制字符串。
  • 可能需要不同的crate，并且只有在500MB预算不足的情况下，即Pie III无法运行时，才会真正实施。

经验教训

• futures::ThreadPools - 惊慌的未来只会崩溃一个线程
• 长时间运行的未来需要错误和可能的恐慌恢复。Futures有一个可能有用的恐慌捕获器。
• sqlite需要大量的调整才能在并发应用程序中正常工作。经验总结：WAL模式，并且在写入时始终使用即时事务。等待时自行重试，并设置一个等待的忙碌处理器。
• 尝试通过美化HTML来优化git输出失败 - 我看不到它有任何改进。对于调试HTML，使用浏览器最简单。

当迁移到Sqlite时

• sqlite…
  • 实际上并不适合许多并发写入者 - 您必须准备数据库锁定错误，并且忙碌处理器大多数时候都无济于事。
  • 写入许多小对象很慢，只能通过预处理语句来缓解，而预处理语句在受sled启发的持久化设计中并不总是可行或方便使用。为了缓解，整个应用程序必须拥抱Sqlite并与语句直接工作。
  • 与事务相关联的生命周期是一个必要的恶行，但在尝试重构任何东西时也非常痛苦！我再也不明白它试图做什么，而且感觉编译器自己也感到困惑（因为在理论上，没有问题）。
• sled数据库比具有相同内容的Sqlite数据库大约大4倍，并且启动时将读取大约1.2GB的14GB数据库。
• sled在线程/并发环境中容易处理，但迭代不能跨越awaits进行，因为它们不是同步的。
  • Sqlite既不是同步的也不是发送的，因此在可以使用spawned futures之前需要更多的处理。
• 使用Sled进行零拷贝很简单，因为它提供了IVec结构体，这些结构体是对LRU的句柄，而LRU是后端存储。
  • 回顾过去，我会将零拷贝视为一个不错的研究实验，但也是一个过早的优化。它需要额外的努力，并且如果从一开始就完成，你甚至不知道通过这种方式实际节省了多少时间。