是否可以在codepen.io中禁用无限循环保护？
JSBin有// noprotect。
能够运行代码而不需要编辑器添加任何内容，这样会很好。在测量执行时间等时。
当我运行CPU分析器时，会调用window.CP.PenTimer.shouldStopLoop（），这可能会导致测量执行时间出错。
在JSBin中，完全相同的代码运行1000毫秒，但在codepen.io中，执行时间为4000毫秒。这使得codepen.io不太适合运行繁重的循环。
示例：
// noprotect
var len = 2000000;
var a = [];
var t = performance.now();
while(len--)
{
a.push((len%7)*Math.atan2(len,-len));
}
t = performance.now() - t;
document.write(t);
在Codepen中： http://codepen.io/timo22345/pen/yYedmo 4202.92毫秒（Chrome 45 OSX）
在JSBin中： http://jsbin.com/xufesa/2/edit?html,css,js,output 1082.03毫秒（Chrome 45 OSX）
这就像巨大的减速使得codepen.io成为一个不错的文本编辑器（在某种程度上它比桌面文本编辑器更接近JSBIN，因为 例如。 tab键按预期工作，可以在其中搜索 iframes），但在代码处于最终状态后，您必须将其移动到 JSBin或其他服务器运行代码 - 如果非限制速度是 重要的事情。
至少有一些警告可以避免完全错误的性能测量和错误的结论。参见例如。 http://www.sitepoint.com/measuring-javascript-functions-performance/其中编写器使用codepen.io测量各种函数的性能，并在测量执行时间后发现使用forEach的函数运行速度明显快于使用plain for循环的函数。他的结论是：
解释很简单但很微妙。使用haystack.forEach的第一个函数受益于浏览器的JavaScript引擎中的一些低级优化，当我们使用数组索引技术时，我们无法获得这些优化。它证明了我们的观点：在你测量它之前你永远不会知道！
Vyacheslav Egorov评论说这不是真的：
一个更明显的解释是实验出了问题......事实确实如此：如果你将一个调试器语句放入for循环，你会发现CodePen工具循环带有抢占检查（以防止无限循环）从猜杀UI，我猜）。这些检查如下所示：
if (window.CP.shouldStopExecution(1)) {
break;
}
答案 0 :(得分：0)