内联 JavaScript 函数调用加快了执行速度,还减少了 gzip 压缩后的代码大小,如本文所述:
http://blog.calyptus.eu/seb/2011/01/javascript-call-performance-just-inline-it/
但是,我找不到自动处理 JS 源文件并在其中内联所有(或更好的,选定的)可内联函数调用的工具。Google 的 Closure Compiler 会进行一些内联,但并非总是如此,也不是可配置的。
提前致谢!
内联 JavaScript 函数调用加快了执行速度,还减少了 gzip 压缩后的代码大小,如本文所述:
http://blog.calyptus.eu/seb/2011/01/javascript-call-performance-just-inline-it/
但是,我找不到自动处理 JS 源文件并在其中内联所有(或更好的,选定的)可内联函数调用的工具。Google 的 Closure Compiler 会进行一些内联,但并非总是如此,也不是可配置的。
提前致谢!
我几乎不相信这种“技术”会加快任何执行时间。至少不是在现实世界的场景中。该博客关于代码大小和 Gzipping 可能是正确的。
无论如何,我认为任何 Javascript 缩小/压缩器都不会这样做。原因很简单,在提供的示例中非常明显。通过用实际的函数代码替换函数调用,您将事情设置到另一个上下文中。这最终可能会非常邪恶。如果父函数(-context)已经声明并使用了一个名为foo的变量怎么办。如果在另一个函数中使用相同的变量,您可能会覆盖它并导致错误。
更糟糕的是,如果使用try/catch
oreval
块创建了一个带有仔细表达的“动态范围”的附加上下文(这实际上在 ecma-script 中不可用)。但是,在这种情况下,JIT 或任何 Javascript 实现几乎不可能优化任何东西。
让 JIT 计算诸如内联之类的事情。内联很容易通过杀死缓存性能来降低性能。
此外,除非您已经确定了实际的瓶颈,否则像这样过早地进行优化几乎是不值得的。