por que a última função é 10% mais rápida, embora precise criar as variáveis ​​repetidamente?

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';
    }
  };
})();

E a função mais rápida: (observe que sempre deve calcular as mesmas variáveis ​​kb / mb / gb repetidas vezes). Onde ele ganha desempenho?

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';
 }
};

Os modernos mecanismos JavaScript fazem compilação just-in-time. Você não pode fazer nenhuma suposição sobre o que "deve criar repetidamente". Esse tipo de cálculo é relativamente fácil de otimizar, em ambos os casos.

Por outro lado, fechar sobre variáveis ​​constantes não é um caso típico para o qual você visaria a compilação JIT. Você normalmente cria um fechamento quando deseja poder alterar essas variáveis ​​em diferentes invocações. Você também está criando uma desreferência adicional de ponteiro para acessar essas variáveis, como a diferença entre acessar uma variável de membro e um int local no OOP.

Esse tipo de situação é o motivo pelo qual as pessoas jogam fora a linha da "otimização prematura". As otimizações fáceis já são feitas pelo compilador.

Variáveis ​​são baratas. Contextos de execução e cadeias de escopo são caros.

Existem várias respostas que se resumem basicamente a "porque fechamentos", e essas são essencialmente verdadeiras, mas o problema não está especificamente no fechamento, é o fato de você ter uma função que faz referência a variáveis ​​em um escopo diferente. Você teria o mesmo problema se essas fossem variáveis ​​globais no windowobjeto, em oposição às variáveis ​​locais dentro do IIFE. Experimente e veja.

Então, na sua primeira função, quando o mecanismo vê esta declaração:

var gbSize = size / GB;

É necessário seguir os seguintes passos:

1. Procure uma variável sizeno escopo atual. (Encontrei.)
2. Procure uma variável GBno escopo atual. (Não encontrado.)
3. Procure uma variável GBno escopo pai. (Encontrei.)
4. Faça o cálculo e atribua a gbSize.

O passo 3 é consideravelmente mais caro do que apenas alocar uma variável. Além disso, você faz isso cinco vezes , incluindo duas vezes para ambos GBe MB. Eu suspeito que, se você aliasse esses itens no início da função (por exemplo var gb = GB) e referenciasse o alias, isso produziria uma pequena aceleração, embora também seja possível que alguns mecanismos JS já executem essa otimização. E, é claro, a maneira mais eficaz de acelerar a execução é simplesmente não atravessar a cadeia de escopo.

Lembre-se de que o JavaScript não é como uma linguagem compilada estaticamente, em que o compilador resolve esses endereços variáveis ​​no momento da compilação. O mecanismo JS deve resolvê-los pelo nome , e essas pesquisas acontecem em tempo de execução, sempre. Então você quer evitá-los quando possível.

A atribuição de variáveis ​​é extremamente barata em JavaScript. Pode ser realmente a operação mais barata, embora eu não tenha nada para fazer backup dessa declaração. No entanto, é seguro dizer que quase nunca é uma boa idéia tentar evitar a criação de variáveis; quase todas as otimizações que você tenta fazer nessa área acabam piorando as coisas, em termos de desempenho.

Um exemplo envolve um fechamento, o outro não. A implementação de fechamentos é meio complicada, pois as variáveis ​​fechadas não funcionam como variáveis ​​normais. Isso é mais óbvio em uma linguagem de baixo nível como C, mas usarei JavaScript para ilustrar isso.

Um fechamento não consiste apenas de uma função, mas também de todas as variáveis ​​que ele encerrou. Quando queremos chamar essa função, também precisamos fornecer todas as variáveis ​​de fechamento. Podemos modelar um fechamento por uma função que recebe um objeto como primeiro argumento que representa essas variáveis ​​fechadas sobre:

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

Observe a convenção de chamada estranha que closure.apply(closure, ...realArgs)isso exige

O suporte a objetos embutidos do JavaScript permite omitir o varsargumento explícito e, em thisvez disso , vamos usar :

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

Esses exemplos são equivalentes a esse código, na verdade, usando closures:

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

Neste último exemplo, o objeto é usado apenas para agrupar as duas funções retornadas; a thisligação é irrelevante. Todos os detalhes de tornar possíveis os fechamentos - passando dados ocultos para a função real, alterando todos os acessos às variáveis ​​de fechamento para pesquisas nesses dados ocultos - são resolvidos pelo idioma.

Mas chamar encerramentos envolve a sobrecarga de passar esses dados extras, e executar um encerramento envolve a sobrecarga de pesquisas nesses dados extras - agravadas pela má localização do cache e, geralmente, por uma desreferência de ponteiro quando comparadas às variáveis ​​comuns -, portanto, não é surpreendente que uma solução que não depende de fechamentos tem melhor desempenho. Especialmente porque tudo o que seu fechamento lhe permite fazer são algumas operações aritméticas extremamente baratas, que podem até ser dobradas constantemente durante a análise.