Benchmark Notes
这个页面的目的，是让性能表述更准确。
引用 benchmark 之前先看这里
ASUN 没有一个适用于所有语言的统一性能倍数。
引用 benchmark 时，建议明确说明：
- 是哪一种语言实现，不要只写 “ASUN”
- 是文本还是二进制
- 是平面数组、深层嵌套，还是极小单对象
- 是吞吐、延迟、round-trip、只编码还是只解码
哪些结论更容易跨语言成立
- 重复行数据上的 token 节省
- 文本载荷通常比重复 key 的 JSON 更小
- 对重复 schema 数据更友好的解析模型
- 同一运行时内，二进制通常比文本更快
哪些结论不能自动迁移
- Rust 的数字不能自动套到 Go、Java、Python 或其它实现
- 原生实现的结果不能直接代表动态运行时
- 二进制 benchmark 不能直接证明文本模式的性能
- 大数组 benchmark 不能直接代表极小单对象
当前生态里的说明
| 语言族 | 说明 |
|---|---|
| Rust | 当前仓库里 benchmark 最成熟，适合看详细快照 |
| Go | 很适合重复结构体和服务型负载 |
| Java | 对托管运行时下的结构化数据也很有竞争力 |
| Python | 更大的优势来自结构更紧凑和 schema 复用，而不是 VM 极限吞吐 |
| C / C++ / Zig | 很适合高吞吐原生场景 |
推荐写法
推荐：
- “Rust 在重复行解码上有明显优势。”
- “二进制模式通常是同一运行时内最快的路径。”
- “性能会随语言与载荷形态变化。”
避免：
- “ASUN 一定比 JSON 快 7 倍。”
- “所有语言实现都有同样的解析提升。”
- “二进制 benchmark 可以直接证明文本模式性能。”