性能优化过程：当前仓库里真正能确认的结论

先说边界

如果只看当前仓库，能明确引用的性能材料主要是：

• doc/benchmark-results-2026-04-26.md
• doc/performance-analysis-2026-04-26.md
• doc/record-format-optimization-log-2026-05-02.md
• script/bench_soak.sh

因此这篇文章只谈这些材料能支撑的结论，把讨论范围放在已经落到仓库里的 benchmark、分析记录和代码路径上。

当前基线结论

benchmark-results-2026-04-26.md 记录了一次 50,000 条、payload-size=128 的对比：

Rendering diagram...

• log_engine_bench: 387732.15 msg/s
• glog_bench: 648441 msg/s
• spdlog_bench: 1024460 msg/s

这组结果更适合被解读为：

• 当前 log_engine 明显慢于纯日志库基准
• 这是预期之内，因为它承担了更多功能路径
• 这些结果是一次本机对比，更适合用来理解当前实现的相对位置

为什么当前实现更慢

从源码和分析文档看，当前成本主要来自这些路径叠加：

Rendering diagram...

• 路由到 shard
• 记录编码
• 可选结构化字段
• 可选 CRC
• temporary_buffer 拼装
• DMA 对齐写入
• tail buffer 管理
• rotate / checkpoint / recovery 相关语义

所以把它直接和 glog、spdlog 的"简单写日志 benchmark"做吞吐对比，本来就是功能更重的一方吃亏。

已经能确认的调优方向

根据 performance-analysis-2026-04-26.md，有几条相对稳定的观察：

1. payload 变大会明显拖慢当前实现

文档中的 payload=128 与 payload=512 对比显示，log_engine 的吞吐下降比 glog、spdlog 更明显。

这和当前实现很一致，因为 payload 变大时，放大的不仅是 I/O 量，还有：

• 编码成本
• CRC 成本
• 内存拷贝成本
• DMA 聚合写的 buffer 处理成本

2. batch_size 需要中间值，不是越大越好

分析文档表明，某些扫描场景下中等 batch 配置优于太小或太大的 batch。

而且当前代码里的 batch_size 是"条数阈值"，它决定了 writer 何时触发一次批量写出。

3. 过高 inflight 并不一定继续带来收益

已有分析也提示 inflight 存在平衡区间。太低吃不满，太高则会引入更多排队、调度和内部聚合开销。

记录格式优化里已经确认的事

record-format-optimization-log-2026-05-02.md 提供了更细的结论：

• timestamp 格式化路径已经做过缓存优化
• CRC 路径仍然是值得持续关注的热点
• 一些"看起来更快"的替代实现并没有稳定收益

这说明当前项目的性能优化已经从"很粗的架构瓶颈"进入了"编码与校验路径的细节瓶颈"阶段。

当前不该继续写成事实的内容

如果后续要继续扩展性能章节，最好把表述限制在仓库可验证的范围内，例如：

• 某个日期下、某组参数上的单机结果
• 参数扫描下的变化趋势
• record format 与 CRC 调整带来的局部收益

这些内容在当前仓库里要么没有出处，要么与实际配置和实现不一致。

更准确的结论

如果只基于当前仓库，可以把性能优化过程总结成下面几句话：

• 当前实现优先保证分 shard 写入、恢复语义、DMA 对齐写出和可查询性
• 因为功能路径更重，吞吐基线低于 glog/spdlog 是预期现象
• 已有文档显示 payload、batch 和 inflight 会明显影响结果
• 记录编码与 CRC 仍然是值得继续优化的热点

结语

真正可信的性能文章，不是数字越大越好，而是每个数字都能在仓库里找到来源。

对 seastar-log-engine 来说，当前最有价值的写法不是编一个"从 38 万到 150 万"的励志故事，而是把源码、脚本和现有 benchmark 文档能证明的事实写清楚。