Lib.rs

待办事项

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

可能的改进

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

经验教训

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

当迁移到 Sqlite 时

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