20

我是否正确地说 JavaScript 代码没有被编译，甚至没有 JIT？如果是这样，这是否意味着评论会影响性能，并且我应该非常小心放置评论的位置？比如尽可能在函数定义的上方和外部放置函数注释，如果我想最大化性能，绝对避免在循环内放置注释？我知道在大多数情况下（至少在非循环情况下），性能的变化可以忽略不计，但我认为这将是一件值得了解和了解的事情，尤其是对于前端/js 开发人员. 另外，在我最近进行的 js 评估中提出了一个相关问题。

4

5 回答 5

29

我是否正确地说 JavaScript 代码没有被编译，甚至没有 JIT？

不会。尽管 JavaScript 传统上是一种“解释型”语言（尽管不一定如此），但大多数 JavaScript 引擎在必要时会即时编译它。V8（Chrome 和 NodeJS 中的引擎）用于立即快速编译，然后返回并积极优化任何经常使用的代码（旧的 FullCodegen+TurboFan 堆栈）；不久前进行了大量实际测量后，他们切换到最初解析为 byteocde 和解释，然后在代码被大量重用时进行编译（新的 Ignition+TurboFan 堆栈），通过不编译运行显着节省内存- 一次设置代码。即使是不那么激进的引擎，几乎可以肯定至少会将文本解析为某种形式的字节码，并尽早丢弃注释。

请记住，“解释”与“编译”通常更多的是环境问题而不是语言问题。有 C 解释器，还有 JavaScript 编译器。语言往往与环境密切相关（就像 JavaScript 往往与 Web 浏览器环境相关联，尽管它的使用范围总是比这更广泛，甚至早在 1995 年），但即便如此（正如我们所见），可能会有变化。

如果是这样，这是否意味着评论会影响性能......

在初始解析阶段，非常非常非常小。但是评论很容易浏览过去，无需担心。

但是，如果您真的担心它，您可以使用诸如Closure Compilerjsmin之类的工具来缩小您的脚本（即使只是简单的优化）。前者只会删除注释和不必要的空格，诸如此类的东西（仍然很有效）；后者这样做并且实际上理解代码并进行一些内联​​等。因此，您可以自由发表评论，然后使用这些工具确保在首次加载脚本时这些评论可能产生的任何微小影响都可以通过使用缩小工具绕过。

当然，关于 JavaScript 性能的问题是很难可靠地预测跨引擎，因为引擎差异很大。所以实验可以很有趣：

  • 这是一个实验，（理论上）每次都重新解析/重新创建函数
  • 这是一个只解析/创建一次函数并重用它的函数

结果？我的看法是，测试的测量误差没有明显的差异。

于 2012-04-19T16:56:59.490 回答
10

注释的最大影响是增大文件大小，从而减慢脚本的下载速度。因此，为什么所有专业网站都使用最小化器来生产高效版本，以将 js 缩减到尽可能小。

于 2012-04-19T16:59:50.597 回答
4

它可能会产生一些影响。不过，效果非常简约（即使 IE6 也能正确处理评论！待确认...）。

然而，大多数人使用一个去除评论的缩小器。所以没关系。

还：

V8 通过在执行 JavaScript 之前将其编译为本机机器代码来提高性能。

来源

于 2012-04-19T16:58:28.480 回答
0

它可以防止函数被内联，这会影响性能，尽管这不应该真的发生。

于 2019-03-29T03:21:03.740 回答
0

在某些可能孤立的情况下，注释肯定会以某种方式阻碍代码执行。我正在编写一个冗长的用户脚本，在 Mac 上使用 TamperMonkey 的最新 Firefox 中使用，当我从脚本中删除冗长的注释时，几天来越来越沮丧的故障排除结束了，突然脚本执行停止完全挂在 Facebook 上。在新用户帐户上运行相同的确切脚本的多次来回比较，唯一的区别是评论，证明情况确实如此。

于 2019-08-14T18:48:40.763 回答