UD5工具箱
如何使用这个 JavaScript 代码计时器？
在代码编辑器中输入您想要测试的 JavaScript 代码（函数体），设置运行次数（建议 1000 至 10000 次以获得稳定结果）和预热次数（让 JIT 编译器优化代码），然后点击"开始计时"。工具会循环执行您的代码，记录每次的耗时，并展示总耗时、平均耗时、最快最慢、中位数、标准差以及每秒操作数（ops/s）等统计指标。您也可以点击预设标签快速加载示例代码进行体验。
performance.now() 和 Date.now() 有什么区别？为什么用 performance.now()？
Date.now() 返回的是 Unix 时间戳（毫秒级），精度仅到毫秒，且受系统时间调整影响。performance.now() 返回从页面加载开始的高精度时间（精度可达微秒级，通常为 5μs 的倍数），不受系统时间变化影响，是 W3C High Resolution Time API 的一部分。对于测量代码执行耗时（尤其是毫秒级以下的操作），performance.now() 是业界标准选择，能提供更准确的测量结果。
为什么需要"预热"（Warmup）？
现代 JavaScript 引擎（如 V8、SpiderMonkey）使用即时编译（JIT）技术。代码在前几次执行时，引擎会进行解释执行和 baseline 编译；随着执行次数增加，引擎识别到"热点代码"后会进行优化编译（Optimizing Compilation），生成更高效的机器码。预热运行可以触发这些优化，使正式计时时的代码处于优化后的稳定状态，得到更真实、更稳定的性能数据。通常 3 至 10 次预热就足够触发大多数 JIT 优化。
如何解读统计结果中的各项指标？
总耗时是所有运行次数的累计时间。平均耗时是单次运行的平均时间，最常用的性能指标。最快最慢是单次运行的最小最大耗时，帮助发现性能波动。中位数是排序后位于中间的耗时值，比平均值更能抵抗极端值干扰。标准差反映各次运行耗时的离散程度，标准差越小性能越稳定。操作/秒（ops/s）是每秒可执行的次数，数值越大性能越好，计算公式为运行次数除以总耗时（秒）。
为什么同段代码多次测试结果会不一样？
这是正常现象，原因包括：第一，垃圾回收（GC）——JavaScript 引擎在运行过程中会间歇性进行垃圾回收，导致某些运行耗时突然增加（在分布图中可看到红色尖峰）；第二，CPU 调度——操作系统将 CPU 时间分配给不同进程或线程，后台任务可能影响测试；第三，JIT 编译抖动——引擎可能在不同优化层级之间切换。为获得可靠结果，建议进行足够多次的运行（1000 次以上），并关注中位数和标准差而非单次数据。
如何优化 JavaScript 代码性能？有哪些常见技巧？
一些实用技巧包括：避免不必要的 DOM 操作，批量更新 DOM 并使用 DocumentFragment；使用 Map 和 Set 替代 Object 和 Array 进行频繁查找（O(1) 对比 O(n)）；减少闭包创建，在循环中避免创建新函数；使用 for 循环替代 forEach，在高性能场景下传统 for 循环通常更快；大量字符串拼接时使用数组 join() 而非加号赋值运算符；缓存计算结果避免重复计算相同的值。您可以使用本工具对比优化前后的代码，量化性能提升效果。
这个工具支持测试异步函数吗？
当前版本主要针对同步代码进行高精度计时。如果您的代码包含异步操作（async/await、Promise、setTimeout 等），由于事件循环的特性，单次运行的耗时测量会变得复杂。您可以将异步逻辑的核心同步部分提取出来进行测试，或者将异步操作包装为同步可测量的单元。未来版本可能会加入专门的异步代码计时模式。
运行次数设置多少比较合适？
这取决于代码的执行速度。极快操作（小于 10μs）如简单算术、属性访问，建议 10000 至 100000 次；中等操作（10μs 至 1ms）如数组排序、字符串处理，建议 1000 至 10000 次；较慢操作（大于 1ms）如 DOM 操作、大量计算，建议 100 至 1000 次。总的原则是让总测试时间在 100ms 至 2s 之间，既能获得足够样本又不让用户等待太久。如果不确定，从 1000 次开始，根据结果调整。
中位数和平均值应该看哪个？
在大多数情况下，中位数比平均值更可靠。平均值容易被极端值拉偏——如果某次运行因为垃圾回收导致耗时特别长，平均值会显著升高，不能反映代码的真实典型性能。而中位数取的是排序后中间位置的值，天然对极端值具有鲁棒性。建议以中位数作为主要参考指标，标准差作为稳定性参考。如果平均值和中位数差距很大，说明存在明显的性能波动，需要排查原因。