# FSST 解码性能优化总结

当前性能基准:
- 解码吞吐: ~4100-4200 MB/s
- 编码吞吐: ~360-380 MB/s
- 压缩率: 50.45%

已尝试的优化方案 (15 个，全部失败或无效):

1. 交错存储 (len+symbol)     → -8.10%  结构体变大，缓存效率下降
2. 分支预测提示 cold_path    → N/A     unstable feature
3. memchr 查找 ESC           → -31.56% 8字节块太小，SIMD 启动开销大
4. 合并双块 ESC 检测         → -0.7%   OR 操作引入额外依赖
5. 32 字节批处理              → -11.85% 分支复杂度上升
6. 软件预取 prefetch         → N/A     unstable feature
7. 减少依赖链                → -9%     寄存器压力上升
8. ESC 快速跳过              → -1.65%  额外位运算开销
9. 前缀和展开                → -11.48% 阻碍编译器优化
10. 延迟加载 block1          → -2.1%   增加关键路径延迟
11. 单块循环                 → 波动    无稳定提升
12. 指针游标优化             → -5.60%  阻碍编译器优化
13. 裸指针替换引用           → 波动    无稳定提升
14. has_esc 简化             → 波动    编译器已优化
15. repr(C) 内存布局         → -0.53%  无明显影响

结论:
当前实现已经非常接近硬件极限。主要瓶颈分析:

1. 内存带宽: 4100 MB/s 的解码吞吐意味着每秒处理约 4GB 数据
   - 考虑到输入输出都需要内存访问，实际内存带宽使用约 8-12 GB/s
   - 这已经接近 M2 芯片的内存带宽利用率

2. 数据依赖: FSST 解码的核心是串行依赖链
   - 每个符号的输出位置依赖于前一个符号的长度
   - 这是算法固有的限制，无法通过并行化解决

3. 分支预测: 当前实现的分支预测命中率已经很高
   - 双块批处理在无 ESC 时走快速路径
   - 进一步优化分支结构反而可能降低性能

4. 指令级并行: 编译器已经做了很好的优化
   - macro 展开的 decode_block 允许 CPU 乱序执行
   - 手动展开反而可能阻碍编译器优化

建议:
- 如需进一步提升，考虑使用 SIMD 指令 (需要 nightly Rust)
- 或者在更高层面优化，如批量解码多个字符串
- 当前实现已经是 stable Rust 下的最优解