基准测试对比器

关于 基准测试对比器

跑完几组性能测试，得到一堆"名称 + 数值"的原始数字，想一眼看出谁快谁慢、差距多大并不容易。本工具把这些测量数据整理成清晰的对比榜单：每行粘贴一个名称和对应数值，工具自动解析、按"越大越好"或"越小越好"排序，算出每项相对于最优项的百分比并画出对比条，还能一键复制成排名报告。它把零散数字变成可读的排行图，适合分享给团队。所有计算均在浏览器本地完成，结果即时呈现，无需等待网络请求，它适合把压测、构建或算法对比得到的零散数字整理成可读的排行，便于在周会或 PR 里分享。对比前先确认各组测试环境一致，并尽量多跑几轮取中位数，避免单次抖动造成误判；榜单给出相对最优项的百分比后，差距是否显著还要结合业务容忍度判断，把结果连同测试条件一起贴进周会更经得起追问。

测量条件不一致是结论失真的首要原因。同一份代码在不同输入规模、不同并发度下表现差别很大，把两次条件不同的测量放在一张榜上比较，得到的差距反映的是条件差异而不是实现差异。因此上榜前应把条件字段（输入规模、并发、硬件、版本）作为必填信息一并记录，让读者能判断可比性。

吞吐与延迟必须分开看，这是性能对比里最常被混淆的一对概念。只看吞吐会掩盖长尾：并发拉高后吞吐可能上升，而最慢的那一小部分请求延迟翻了几倍，用户体验反而变差。因此结论应同时给出吞吐与百分位延迟，并且明确说明百分位是哪一个，否则「平均延迟」会掩盖真正的问题。

单次测量的波动往往被低估。受缓存预热、后台任务与调度影响，同一配置连续测量可能相差百分之几到十几，这让微小的差距失去意义。稳妥做法是重复若干轮取中位数或去掉首尾后的均值，并把波动范围一并列出，让读者知道多大的差距才算真实差异。

与「压测」的分工需要区分：基准测量关心的是「在受控条件下谁更快」，压测关心的是「在压力下何时开始失败」。两者的输入与结论都不同，把压测结果当作基准结论来用，会得到「某方案在高并发下变慢」这种其实属于容量问题的判断。按目标选择方法，而不是用一把尺子量所有问题。

最后，把测量脚本与原始数据一起留存是让结论可信的关键。榜单只是结论，脚本记录了方法，原始数据则允许他人用不同方式重新分析。三者齐备时，结论可以被核对与复现；只有榜单时，任何疑问都只能靠信任，这在团队内部的技术决策里通常不够。

还有一个前提与呈现方式有关：榜单用排序表达强弱，但读者容易忽略「差距是否显著」。因此建议在榜上直接标注相对差异的百分比，或把落在波动范围内的条目并列为同一档，避免把一个百分之二的差距呈现得与两倍差距同样醒目，这正是排序表达最容易误导的地方。