我希望我的处理器越快，我的代码运行得越快。
我可以使用毫秒精度测量代码。
new Date.getTime()
两者之间有什么关联？
我怎么能指望这与运行在 3.2 GHz 的处理器有关。
任何人都可以量化这种关系，即使这是一个非常粗略的估计？
// start_time
run some simple code to be timed.
// end_time
【问题讨论】：
标签： javascript performance benchmarking
分配给 JS 脚本的 [EDIT: CPU] 时钟时间由多种因素决定，包括：
可以在 Windows 8 的高级电源选项菜单中看到一个演示。展开 Internet Explorer 节点，您会注意到下面的条目是 JavaScript timer frequency。这正是你所想的——一个控制 JS 时钟“滴答”频率的设置。一秒钟内的滴答声越多，JS 引擎执行代码的频率就越高，执行的代码越多，消耗的功率就越多。
所以回答你的问题： 是的，在一般意义上，处理器时钟速度可以决定特定 JS 的运行速度，但假设它是直接相关是错误的。
编辑（更多信息）：
我无法挖掘链接，但如果我找到它，我会在这里更新。使用setTimeout 或setInterval，您可以传递给那些实际将被兑现的方法的最小时间单位是100(ms)。可能有比这更高的频率，但保证 100 毫秒是唯一的
我发现了一些与我在这篇文章中的想法相近的东西： http://javascript.info/tutorial/settimeout-setinterval
本质上，在基于队列操作的 JavaScript 计时器中——您可以调用 setTimeout(fn, 10)，您的请求将在 10 毫秒后排队执行，但这并不意味着它会得到在那段时间之后执行，只是它排队等待这样做。如果您测量预期和实际之间的差异（超过阈值，可能是 100 毫秒），您可以收集偏移数据来计算脚本运行的结果频率（或“时钟速度”）。请参阅this article 以获取更精确的 JS 基准测试示例
从第二篇文章中，我们看到您可以获得的最小超时时间是 4 毫秒：
使用 setTimeout 测量图形性能是另一个坏主意。 setTimeout 间隔在浏览器中被限制为 4 毫秒，因此您最多可以得到 250 FPS。从历史上看，浏览器有不同的最小间隔，所以你可能有一个非常糟糕的琐碎绘图基准，显示浏览器 A 以 250 FPS（最小间隔 4 毫秒）运行，浏览器 B 以 100 FPS（最小间隔 10 毫秒）运行。显然A更快！不是！很可能 B 运行绘图代码的速度比 A 快，比如 A 用了 3 毫秒，B 用了 1 毫秒。不影响 FPS，因为绘制时间小于最小 setTimeout 间隔。如果浏览器异步渲染，所有的赌注都没有了。除非您知道自己在做什么，否则不要使用 setTimeout。
【讨论】：
setTimeout的编辑