请记住，那年，面试官问如何测试一项操作的速度（执行时间），然后我像这样回来了。
但是这个方案是错误的
为什么？
此操作的具体操作会消耗如此长的时间。它总是以这种速度运行，基本上一无所知。在其他时候运行速度更快。较低的信任测试几乎无法支持任何支持您的决定。这项绩效测试基本没有用。
许多人可以将其包装在周期中，以便整个测试进行更长的时间。如果您重复100次操作，然后整个周期报告总共消耗137ms，那么您可以用100次将其删除并获得平均时间每个操作都是1.37ms，但这是错误的。
简单的数学平均水平绝对不足以判断您在整个应用程序范围内的性能。100次迭代，即使只有少数（太高或低）异常值也会影响整个平均水平，然后在应用此应用时会影响整个平均水平结论，您将传播此错误并产生更大的欺骗。
我不打算重复他们的整个文档来介绍如何通过Benchmark.js.s.the Api进行操作，您应该阅读它。还有一些很棒的文章，介绍了更多的详细信息和方法，例如此处（http：http：http：http：http：http：//calendar。plyplanet.com/2010/bulletprof-javascript-benchmarks）（http://monsur.hosa.in/2012/112/11/benchmarksjs.html）。
测试条件更接近您期望的真实情况。仅此的结果就可以接近事实。
Benchmark.js库在JSPERF早些时候引入以运行统计准确和可靠的测试，并将测试结果放在开放URL上，您可以将此URL转发给其他URL。
要编写良好的测试，我们需要仔细分析并考虑两个测试案例之间的差异，这些差异是有意或无意的。
不要试图缩小到真实代码的微小片段，并测量上下文的这一小部分的性能，因为功能测试和性能测试在包含较大（仍然有意义的）上下文时会更好这些测试也可能较慢，这意味着在环境中发现的任何差异都更有意义。
很多时候，我们通过代码进行的某些性能优化在引擎眼中可能并没有很大差异，例如++的行为我喝了i ++。
发动机可以自由地确定是否需要优化操作，可以权衡并替换计算的性能。对于操作，很难找到使其在所有浏览器中运行速度更快的方法。
您怎么知道总体情况是什么？首先，您需要了解您的代码是否在关键路径上运行。如果您不在关键路径上，那么优化可能不会获得很多好处。
呼叫调用是一个函数调用，出现在另一个函数“结束”中。此呼叫结束后，没有其他事情要做。
非传播尾巴呼叫：
foo（y+1）是bar（..）中的尾声，因为在完成后，也完成了bar（..），只有foo（..）呼叫的结果是条件。但是，bar（40）不是尾声，因为完成后，其结果需要添加到1（）。