【问题标题】:Debugging error message: "A script on this page is causing Internet Explorer to run slowly"调试错误消息:“此页面上的脚本导致 Internet Explorer 运行缓慢”
【发布时间】:2014-02-27 20:42:35
【问题描述】:

我的一个用户在 IE 8 中间歇性地得到一个对话框,上面写着:

此页面上的脚本导致 Internet Explorer 运行缓慢

这个问题已经在 MSDN 论坛和网络上的其他地方多次报告。例如:

所以,这个问题与这些问题和许多其他问题重复。但这是故意重复的,因为我认为这些问题中的任何一个都没有以帮助用户(开发人员)准确确定他的场景中导致对话框出现的方式的方式得到回答。

我知道根据这个页面:

http://support.microsoft.com/kb/175500

当新脚本开始执行(通过多种方式)执行了一定数量的语句时,将出现该对话框。默认情况下,语句数为 5,000,000,但这可以通过注册表项进行配置。

解决这个问题的一般方法是:

  • 少写代码。不幸的是,这并不总是可行的。
  • 使用网络工作者。这不是 IE 10 之前的 IE 的选项,也不是 一些移动浏览器。
  • 使用 setTimeOut、setInterval、事件处理程序等来打破 脚本。这是适用于所有浏览器的合法策略。

所以,我大致了解问题是什么,并且我了解解决问题的选项是什么,再次笼统地说。问题是,如何确定代码的哪些区域导致特定用户出现对话框?这个问题通常发生在非常大的代码库(包括第三方库)中,因此在没有一些工具支持的情况下手动审查代码库是不可行的。

大多数浏览器(包括 IE8 及更高版本)都具有分析工具,可让开发人员确定 JavaScript CPU 使用率。除了 IE,其他浏览器决定脚本是否长时间运行不是基于执行的语句数量,而是基于脚本执行的时间量。为此,浏览器中(或作为附加组件)可用的分析器可以识别执行一个函数所花费的百分比,通常是原始时间,包括和专门用于一个函数,并且可以对结果进行相应的排序。 IE 的分析器还会计算一个函数被调用的频率。这些分析器都没有告诉您在分析期间执行了函数中的代码语句数;他们只告诉你在函数中花费了多长时间以及函数被调用了多少次。这对 IE 的慢速脚本对话逻辑没有帮助,该逻辑基于已执行的语句数(而不是时间)。有时在执行函数所花费的时间和语句数量之间存在相关性,但这不是一种可靠的关系,因为当然不同类型的语句可能需要非常不同的时间来执行(例如,许多原生 JavaScript 函数比更新 DOM 的调用;两者的语句数相同,但前者的执行速度比后者快,因此检查 %/raw time 不是很有用)。

我使用的一种有价值的方法是,当慢速脚本对话框出现时,在 IE 中启动调试器(如果尚未启动)并在调试器中选择 break on next statement 命令。然后单击浏览器中允许慢速脚本继续执行的对话框按钮。此时,调试器被调用,开发人员可以检查调用堆栈以确定慢速脚本对话框出现时正在执行的操作。这没关系,但这是一种非常手动的方法,并且不能保证不会有多个脚本在运行,可以在不同的时间调用对话框。

我看到的一个有趣的想法是使用 JavaScript 代码覆盖工具来检测代码库。有多种 JavaScript 代码覆盖选项,但可以动态检测代码的浏览器扩展的易用性似乎是一个理想的解决方案。 (另一个有趣的想法是使用代理服务器,例如http://siliconforks.com/jscoverage/manual.html; 'jscoverage --server --proxy',但我无法让它在几乎任何网站上工作,除了硅叉网站本身)。有一个可用于 Chrome (http://googletesting.blogspot.ca/2011/10/scriptcover-makes-javascript-coverage.html) 的概念证明,我认为这可能是帮助解决脚本缓慢问题的一个很好的开始——如果可以为 IE 制作这样的扩展。

所以,重申一下我的主要问题是,可以使用哪些工具/流程来调试/分析出现在用户机器上的慢速脚本对话框?一个子问题是,是否有人知道任何 JavaScript 代码分析工具可以重新用于帮助诊断 IE 中的慢速脚本对话框,并且需要最少的部署工作?理论上是否可以编写一个 IE 扩展来实现与 Google 的脚本覆盖扩展一样的代码覆盖率?

谢谢,

巴黎

【问题讨论】:

  • 嗯,没有人有时间阅读所有内容。阅读完所有内容后,您基本上是在要求一种工具,而这些问题通常会被关闭。
  • 我很欣赏它很长,但我希望有人会花时间。我试图描述我已经完成的研究。
  • 嗨@Notre你检查过任何JS分析器吗?看起来 firebug 和 chrome 开发者工具很适合开始。这篇文章可能会有所帮助:coding.smashingmagazine.com/2012/06/12/… 还有这个:getfirebug.com/javascript
  • 嗨@artuc。是的,我做到了。问题是这些分析器将报告函数中使用的时间量,而不是执行了多少语句。 IE 关心的是语句的数量而不是时间(与其他查看时间的浏览器相比)。不过,总的来说,我是这些分析器的忠实粉丝。

标签: javascript performance internet-explorer


【解决方案1】:

在过去,JavaScript 的使用并不多。对我来说,页面更静态。这些天来,PC 的功率较低,在服务器上运行复杂任务更受欢迎。 JavaScript 仅用于某些动画。

微软(不管我怎么做)花时间承认大量 JavaScript 内容。 (他们还在 IE8 中摆弄他们的 JScript)。在 IE9 之前,他们认为在脚本中运行 > 5 000 000 条指令是一个潜在的错误。

我不知道有任何工具可以检索指令计数。这是一个浏览器内置功能。

但大多数浏览器都会检索函数的执行时间。我知道在每台不同的计算机上,相同数量的指令可能需要不同的时间,但你可以设置一个基准。

在机器上运行一个包含 5 000 000 条指令的脚本,看看运行需要多长时间。然后利用这段时间对您的其他 JavaScript 进行基准测试。它不是 100 % 准确的,但一旦你摆弄它,它就会变得很接近。

由于旧的 IE 开发工具很差,您可以使用一些第三方工具。这里的用法示例: deep-tracing-of-internet-explorer

无论如何,“此页面上的脚本导致您的计算机运行缓慢......”只是 IE4 - IE8 中的问题。既然那些浏览器已经过时了,那么这个问题也应该如此。

【讨论】:

  • 不幸的是,IE 8 并没有过时。 Win XP 已过时,但 MS 支持 IE 8,直到 Windows 7 达到生命周期结束,这将是相当长的一段时间。它还拥有相当大的市场份额,尤其是在企业环境中。 IE 8 会根据执行的语句数弹出该对话框,而不是像其他浏览器那样响应时间:(
  • 我想说的是,至少 IE8 的开发应该已经过时了。我会鼓励用户更新和开发者少担心它,但大公司阻止了这一点!
  • 我完全同意 - 它应该已经过时了。总有一天,它会,但直到那一天,它令人沮丧:(
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-03-02
  • 1970-01-01
  • 1970-01-01
  • 2011-08-07
  • 1970-01-01
  • 2012-04-12
  • 1970-01-01
相关资源
最近更新 更多