为什么后者函数必须一遍又一遍地创建变量，但为什么却快10％？

var toSizeString = (function() {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

  return function(size) {
    var gbSize = size / GB,
        gbMod  = size % GB,
        mbSize = gbMod / MB,
        mbMod  = gbMod % MB,
        kbSize = mbMod / KB;

    if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
    } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
    } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
    } else {
      return size + 'B';
    }
  };
})();

还有更快的功能：（请注意，它必须始终一遍又一遍地计算相同的变量kb / mb / gb）。它在哪里获得性能？

function toSizeString (size) {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

 var gbSize = size / GB,
     gbMod  = size % GB,
     mbSize = gbMod / MB,
     mbMod  = gbMod % MB,
     kbSize = mbMod / KB;

 if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
 } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
 } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
 } else {
      return size + 'B';
 }
};

现代的JavaScript引擎都可以即时编译。您不能对其“必须一遍又一遍地创建”进行任何假设。无论哪种情况，这种计算都相对容易优化。

另一方面，关闭常量变量并不是针对JIT编译的典型情况。当您希望能够在不同的调用中更改这些变量时，通常会创建一个闭包。您还将创建一个额外的指针取消引用来访问这些变量，例如访问成员变量和OOP中的本地int之间的区别。

这种情况就是为什么人们抛弃“过早优化”的原因。简单的优化已经由编译器完成。

变量很便宜。执行上下文和作用域链很昂贵。

从本质上讲，有多种答案可以归结为“因为闭包”，而这些答案基本上是正确的，但是问题并不是专门针对闭包，这是因为您有一个函数引用了不同范围内的变量。如果这些是window对象上的全局变量，而不是IIFE中的局部变量，那么您将遇到同样的问题。试试看。

因此，在第一个函数中，当引擎看到以下语句时：

var gbSize = size / GB;

它必须采取以下步骤：

1. size在当前范围内搜索变量。（找到了。）
2. GB在当前范围内搜索变量。（未找到。）
3. GB在父范围中搜索变量。（找到了。）
4. 进行计算并分配给gbSize。

步骤3比分配变量要昂贵得多。此外，这样做五次，其中两次都GB和MB。我怀疑如果您在函数的开头（例如var gb = GB）对它们进行了别名并引用了别名，则实际上会产生很小的提速，尽管某些JS引擎也可能已经执行了此优化。当然，加速执行的最有效方法就是根本不遍历作用域链。

请记住，JavaScript不同于编译器在编译时解析这些变量地址的静态类型语言。JS引擎必须按名称解析它们，并且这些查找每次都在运行时发生。因此，您希望尽可能避免使用它们。

变量赋值在JavaScript中非常便宜。实际上，这可能是最便宜的操作，尽管我没有什么可以支持该声明的。但是，可以肯定地说，避免创建变量几乎从来不是一个好主意。实际上，您尝试在该领域中进行的所有优化最终都会使性能恶化。

一个示例涉及闭包，而另一个则不涉及。实现闭包有点棘手，因为对变量的闭包不能像普通变量那样工作。在像C这样的低级语言中，这一点更加明显，但是我将使用JavaScript进行说明。

闭包不仅包含一个函数，而且还包含它所封闭的所有变量。当我们想调用该函数时，我们还需要提供所有封闭的变量。我们可以通过一个函数来对闭包进行建模，该函数接收一个对象作为第一个参数，该对象表示这些封闭变量：

function add(vars, y) {
  vars.x += y;
}

function getSum(vars) {
  return vars.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(adder, 2);
console.log(adder.getSum(adder));  //=> 42

请注意closure.apply(closure, ...realArgs)这需要的尴尬的调用约定

JavaScript的内置对象支持使省略显式vars参数成为可能，并让我们this改为使用：

function add(y) {
  this.x += y;
}

function getSum() {
  return this.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

这些示例实际上等于使用闭包的以下代码：

function makeAdder(x) {
  return {
    add: function (y) { x += y },
    getSum: function () { return x },
  };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

在最后一个示例中，该对象仅用于对两个返回的函数进行分组。该this结合是无关紧要的。语言会处理所有使闭包成为可能的细节-将隐藏数据传递给实际函数，将对闭包变量的所有访问权限更改为该隐藏数据中的查找-均由语言负责。

但是，调用闭包会带来传入额外数据的开销，而运行闭包会带来在该额外数据中查找的开销–由于缓存位置不佳以及与普通变量相比，指针的取消引用而使情况更加糟糕–因此，不依赖闭包的解决方案效果更好。特别是由于闭包为您节省的所有工作都是一些非常便宜的算术运算，这些运算甚至可能在解析过程中不断折叠。