自动内联 JavaScript 函数调用的工具？答案

【问题标题】：Tool to automatically inline JavaScript function calls?自动内联 JavaScript 函数调用的工具？
【发布时间】：2011-08-25 22:46:44
【问题描述】：

内联 JavaScript 函数调用可加快执行速度，并减少 gzip 压缩后的代码大小，如本文所述：

http://blog.calyptus.eu/seb/2011/01/javascript-call-performance-just-inline-it/

但是，我找不到能够自动处理 JS 源文件并内联所有（或更好，选择的）可内联函数调用的工具。 Google 的 Closure Compiler 会进行一些内联，但并非总是如此，也不是可配置的。

提前致谢！

【问题讨论】：

您不需要内联所有内容，这会使重用代码变得更加困难。我建议您只使用 Google Closure Compiler 之类的东西，它确实执行了许多优化（包括内联）并使代码更小。
这是一个值得更好回答的好问题。在处理重复性任务时，内联通常会产生巨大的影响。例如连续处理像素或计算噪声。

标签： javascript inline-functions

【解决方案1】：

我几乎不相信这种“技术”会加快任何执行时间。至少不是在现实世界的场景中。该博客关于代码大小和 Gzipping 可能是正确的。

无论如何，我认为任何 Javascript 缩小/压缩器都不会做到这一点。原因很简单，在提供的示例中非常明显。通过用实际的函数代码替换函数调用，您将事情设置到另一个上下文中。这最终可能会非常邪恶。如果父函数（-context）已经声明并使用了一个名为foo的变量怎么办。如果在另一个函数中使用相同的变量，您可能会覆盖它并导致错误。

更糟糕的是，如果使用 try/catch 或 eval 块创建了一个带有仔细表达的“动态范围”的附加上下文（这实际上在 ecma-script 中不可用）。但是，在这种情况下，JIT 或任何 Javascript 实现几乎不可能优化任何内容。

【讨论】：

JIT 引擎和静态分析工具（如闭包编译器）在决定内联函数时会考虑范围变化的影响。
当然，但是如果try/catch 或eval 在上下文中涉及所有决策的“解决方案”归结为“不做任何事情”afaik。
“如果内联工具不能正常工作，它可能会破坏你的代码”并不是一个明智的反对意见。您应该假设任何成熟的内联工具都可以用于其预期目的，就像您假设您的编译器正确编译您的代码或您的解释器正确运行它一样。

【解决方案2】：

让 JIT 计算诸如内联之类的事情。内联很容易通过杀死缓存性能来降低性能。

此外，除非您确定了实际的瓶颈，否则像这样过早地进行优化几乎是不值得的。

【讨论】：

-1 这并不能真正回答问题。内联在某些情况下可能是有益的，例如在主循环的迭代中。
相同。问题：我如何解决 X。答案：不要解 X。 StackOverflow：太棒了！真的吗？你不是 OP 知道它的动机。或者某人谷歌搜索该问题的动机，实际上需要答案。 -1
来自 Facebook 的人，请不要对@Ivo Wetzel 投反对票。这就是所谓的投票欺诈，这不是一件好事。
如果你稍微改写一下这个答案，那么它就公然回答了这个问题：“是的，有一个自动内联 Javascript 函数的工具，它被称为 JIT，你已经在使用它了”。