在做性能优化这件事上，最让人头疼的往往不是改代码，而是回答那句追问：到底快了多少，快在哪里，证据能不能复现？
我在一次 CRM 系统迁移到 SAP HANA 的项目里，就被这个问题反复“拷打”过。业务侧希望看到量化的收益，技术侧希望定位到具体热点，团队还希望把结论沉淀成可复用的方法论——这就天然需要一套严谨的 benchmark 流程。
当时我们的计划很朴素：同一份测试报表，在 HANA 系统与非 HANA 系统上各跑一次，用 SAT 做运行时跟踪，把 HANA 系统的 trace 导出成 XML，导入到另一个系统里用 SAT 做对比分析。(development906.rssing.com)
思路听起来很合理，落地却处处踩坑，最后逼着我们把工具链补齐，才把这条路走通。
下面把这套实践完整展开：你会看到 SAT 本身的能力边界在哪里、为什么标准导出/对比会卡死、如何用可裁剪下载把 trace 从 147 MB 压到 84 KB、如何实现更稳定的对比报表，以及在 S/4HANA、CDS、RAP、Gateway 场景里怎么把这套思路继续用下去。
为什么要把 benchmark 做到“可复现”
性能对比只要出现一次不一致，所有结论都会被质疑。比如同一段逻辑：
- 测试参数不一致
- 缓冲区状态
