почему последняя функция на 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-компиляцию. Обычно вы создаете замыкание, когда хотите иметь возможность изменять эти переменные при разных вызовах. Вы также создаете дополнительный разыменование указателя для доступа к этим переменным, например разницу между доступом к переменной-члену и локальным 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связывание не имеет значения. Все детали создания возможных замыканий - передача скрытых данных в реальную функцию, изменение всех обращений к переменным замыкания для поиска в этих скрытых данных - решаются языком.

Но вызовы замыканий включают в себя издержки передачи этих дополнительных данных, а выполнение замыканий включает издержки поиска в этих дополнительных данных, что усугубляется плохой локальностью кэша и обычно разыменованием указателя по сравнению с обычными переменными, так что неудивительно, что решение, которое не зависит от замыканий, работает лучше. Тем более, что все, что спасает ваше закрытие, - это несколько чрезвычайно дешевых арифметических операций, которые могут быть даже сложены во время анализа.