没有局部函数不是微优化吗？

Question

将内部函数移到该函数之外，以便每次调用该函数时都不会创建它是否是一种微优化？

在这种特殊情况下，doMoreStuff 函数仅在 doStuff 内部使用。我应该担心有这样的本地功能吗？

function doStuff() {
    var doMoreStuff = function(val) {
         // do some stuff
    }

    // do something
    for (var i = 0; i < list.length; i++) {
         doMoreStuff(list[i]);
         for (var  j = 0; j < list[i].children.length; j++) {
              doMoreStuff(list[i].children[j]);
         }
    }
    // do some other stuff

}

一个实际的例子是：

function sendDataToServer(data) {
    var callback = function(incoming) {
         // handle incoming
    }

    ajaxCall("url", data, callback);

} 

Answer 1

在普通 PC 上运行的快速“基准”（我知道有很多未解释的变量，所以不要评论明显的变量，但无论如何它都很有趣）：

count = 0;
t1 = +new Date();
while(count < 1000000) {
  p = function(){};
  ++count;
}
t2 = +new Date();
console.log(t2-t1); // milliseconds

例如，可以通过将增量移动到条件来优化（运行时间减少了大约 100 毫秒，尽管它不会影响有函数创建和无函数创建之间的差异，所以它并不真正相关）

运行 3 次给出：

913
878
890

然后注释掉该函数创建行，运行 3 次给出：

462
458
464

因此，纯粹在 1000,000 个空函数创建上，您会增加大约半秒。即使假设您的原始代码在手持设备上每秒运行 10 次（假设该设备的整体性能是该笔记本电脑的 1/100，这有点夸张 - 它可能更接近 1/10，尽管会提供一个不错的上限） ，这相当于这台计算机上每秒创建 1000 个函数，只需 1/2000 秒。因此，手持设备每秒都会增加 1/2000 秒的处理开销……每秒半毫秒并不算多。

从这个原始测试中，我得出的结论是，在 PC 上这绝对是一种微观优化，如果您正在为较弱的设备进行开发，那么几乎肯定也是如此。

Answer 2

不确定这是否属于“微优化”类别。我会说不。

但这取决于您调用doStuff的频率。如果您经常调用它，那么一遍又一遍地创建该函数是不必要的，而且肯定会增加开销。

如果您不想在全局范围内拥有“辅助函数”，但又避免重新创建它，您可以像这样包装它：

var doStuff = (function() {
    var doMoreStuff = function(val) {
         // do some stuff
    }
    return function() {
        // do something
        for (var i = 0; i < list.length; i++) {
            doMoreStuff(list[i]);
        }
        // do some other stuff 
    }
}());

由于返回的函数是一个闭包，因此它可以访问 doMoreStuff 。请注意，外部函数会立即执行 ( (function(){...}()) ）。

或者您创建一个包含对函数的引用的对象：

var stuff = {
    doMoreStuff: function() {...},
    doStuff: function() {...}
};

---

有关封装、对象创建模式和其他概念的更多信息可以在书中找到 JavaScript 模式。

Answer 3

最初的问题是在 2011 年提出的。鉴于此后 Node.js 的兴起，我认为值得重新审视这个问题。在服务器环境中，这里或那里的几毫秒可能非常重要。在负载下保持响应与否之间可能存在差异。

虽然内部函数在概念上很好，但它们可能会给 JavaScript 引擎的代码优化器带来问题。下面的例子说明了这一点：

function a1(n) {
    return n + 2;
}

function a2(n) {
    return 2 - n;
}

function a() {
    var k = 5;
    for (var i = 0; i < 100000000; i++) {
        k = a1(k) + a2(k);
    }
    return k;
}

function b() {
    function b1(n) {
        return n + 2;
    }

    function b2(n) {
        return 2 - n;
    }

    var k = 5;
    for (var i = 0; i < 100000000; i++) {
        k = b1(k) + b2(k);
    }
    return k;
}

function measure(label, fn) {
    var s = new Date();
    var r = fn();
    var e = new Date();
    console.log(label, e - s);
}

for (var i = 0; i < 4; i++) {
    measure('A', a);
    measure('B', b);
}

运行代码的命令：

node --trace_deopt test.js

输出：

[deoptimize global object @ 0x2431b35106e9]
A 128
B 130
A 132
[deoptimizing (DEOPT eager): begin 0x3ee3d709a821 b (opt #5) @4, FP to SP delta: 72]
  translating b => node=36, height=32
    0x7fffb88a9960: [top + 64] <- 0x2431b3504121 ; rdi 0x2431b3504121 <undefined>
    0x7fffb88a9958: [top + 56] <- 0x17210dea8376 ; caller's pc
    0x7fffb88a9950: [top + 48] <- 0x7fffb88a9998 ; caller's fp
    0x7fffb88a9948: [top + 40] <- 0x3ee3d709a709; context
    0x7fffb88a9940: [top + 32] <- 0x3ee3d709a821; function
    0x7fffb88a9938: [top + 24] <- 0x3ee3d70efa71 ; rcx 0x3ee3d70efa71 <JS Function b1 (SharedFunctionInfo 0x361602434ae1)>
    0x7fffb88a9930: [top + 16] <- 0x3ee3d70efab9 ; rdx 0x3ee3d70efab9 <JS Function b2 (SharedFunctionInfo 0x361602434b71)>
    0x7fffb88a9928: [top + 8] <- 5 ; rbx (smi)
    0x7fffb88a9920: [top + 0] <- 0 ; rax (smi)
[deoptimizing (eager): end 0x3ee3d709a821 b @4 => node=36, pc=0x17210dec9129, state=NO_REGISTERS, alignment=no padding, took 0.203 ms]
[removing optimized code for: b]
B 1000
A 125
B 1032
A 132
B 1033

如您所见，函数 A 和 B 最初以相同的速度运行。然后由于某种原因发生了去优化事件。从那时起，B 几乎慢了一个数量级。

如果您正在编写性能很重要的代码，那么最好避免使用内部函数。

Answer 4

为了获得嵌套函数（外部函数的内部范围内的函数）的最佳速度，我怀疑您应该使用声明，而不是表达式。

该问题询问“局部函数”和优化，但没有指定如何创建局部函数。但它应该如此，因为对于创建“内部函数”的不同技术，问题的答案可能是不同的。

看看@cleong的答案和测试结果，我怀疑只有他的答案是使用最佳技术来创建函数。创建函数有三种方法，@cleong 向我们展示了提供快速执行的方法。这三种技术是：

• 构造函数
• 声明
• 表达式

构造函数用得不多，它需要一个包含函数体文本的字符串。这在反射编程中非常有用，您可以执行“toString()”来获取函数体，修改，然后构造一个新函数。当然，这或多或少从未做过。

使用声明，但主要用于外部函数，而不是内部函数（“内部函数”是指嵌套在另一个函数中的函数）。然而，根据 @cleong 测试，它似乎非常快；与外部函数一样快。

表达式是每个人都使用的。这可能不是最好的主意；但这是每个人都会做的。

函数声明和函数表达式之间的一个主要区别是声明会受到提升。每个人都知道“var”声明被提升；但“函数”声明也是如此。对于提升的事物，在编译时执行计算以确定该事物所需的内存空间。据推测，人们会期望内部函数在编译时进行编译，并且可以像编译后的外部函数一样运行。

我有一本大约六年前弗兰尼根的《权威指南》一书，我记得读过我刚刚在这里写的内容的反面。他说了这样的话：表达式是编译的，而声明不是。虽然他是世界上 JavaScript 的“权威指南”，但我一直怀疑他可能把这本指南搞混了。我怀疑函数内部声明比函数表达式更“准备就绪”。 stackOverflow 页面上的测试结果似乎证实了我长期以来的怀疑。

看看 @cleong 测试结果，如果考虑最佳执行速度，似乎声明而不是表达式才是内部函数的最佳选择。

Answer 5

这完全取决于函数被调用的频率。如果它是每秒调用 10 次的 OnUpdate 函数，那么这是一个不错的优化。如果每页调用三次，则属于微优化。

虽然嵌套函数定义很方便，但从来不需要（它们可以被函数的额外参数替换）。

嵌套函数的示例：

function somefunc() {
    var localvar = 5

    var otherfunc = function() {
         alert(localvar);
    }

    otherfunc();
}

同样的事情，现在用参数代替：

function otherfunc(localvar) {
    alert(localvar);
}

function somefunc() {
    var localvar = 5

    otherfunc(localvar);
}

Answer 6

这绝对是一个微观优化。首先使用函数的全部原因是为了让你的代码更干净、更易于维护和更具可读性。函数向代码段添加语义边界。每个函数应该只做一件事，而且应该干净利落地完成。因此，如果您发现您的函数同时执行多项操作，那么您就可以将其重构为多个例程。

仅当某些工作运行速度太慢时才进行优化（如果它尚未工作，则优化还为时过早。期间）。请记住，没有人会为比他们的需要/要求更快的程序支付额外费用...

编辑：考虑到该程序尚未完成，这也是一个过早的优化。为什么这么糟糕？嗯，首先你花时间做一些从长远来看可能不重要的事情。其次，您没有基准来查看您的优化是否在现实意义上改进了任何东西。第三，在运行之前就降低了可维护性和可读性，因此与使用干净简洁的代码相比，运行起来会更困难。第四，你不知道程序中的其他地方是否需要 doMoreStuff ，直到你完成它并了解你的所有需求（也许不太可能，具体取决于具体的细节，但不会超出范围）可能性的领域）。

Donald Knuth 说过早的优化是万恶之源是有原因的......