Değişkenleri tekrar tekrar oluştursa da, ikinci işlev neden% 10 daha hızlı?

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

Ve daha hızlı fonksiyon: (her zaman aynı değişkenleri kb / mb / gb tekrar tekrar hesaplaması gerektiğini unutmayın). Nerede performans kazanıyor?

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

Modern JavaScript motorlarının hepsi tam zamanında derleme yapar. "Tekrar tekrar yaratması gerekenler" hakkında herhangi bir varsayımda bulunamazsınız. Her iki durumda da, bu tür bir hesaplamanın optimize edilmesi nispeten kolaydır.

Öte yandan, sabit değişkenleri kapatmak JIT derlemesini hedefleyeceğiniz tipik bir durum değildir. Bu değişkenleri farklı çağrılarda değiştirmek istediğinizde genellikle bir kapak oluşturur. Ayrıca, bu değişkenlere erişmek için üye değişkene erişim ile OOP'de yerel int arasındaki fark gibi ek bir işaretçi referansı da oluşturuyorsunuz.

Bu tür bir durum insanların "erken optimizasyon" çizgisini atmasının nedenidir. Kolay optimizasyonlar derleyici tarafından zaten yapılmıştır.

Değişkenler ucuzdur. Yürütme bağlamları ve kapsam zincirleri pahalıdır.

Temel olarak "çünkü kapanışlar" a kaybolan çeşitli cevaplar vardır ve bunlar esasen doğrudur, ancak problem özellikle kapanma ile ilgili değildir , değişkenleri farklı bir kapsamda referans alan bir fonksiyona sahip olmanızdır. Bunlar window, IIFE içindeki yerel değişkenlerin aksine , nesnede global değişkenler olsaydı aynı sorunu yaşarsınız. Deneyin ve görün.

İlk fonksiyonunuzda, motor bu ifadeyi gördüğünde:

var gbSize = size / GB;

Aşağıdaki adımları atmalıdır:

1. sizeGeçerli kapsamda bir değişken arayın . (Buldum.)
2. GBGeçerli kapsamda bir değişken arayın . (Bulunamadı.)
3. GBÜst kapsamda bir değişken arayın . (Buldum.)
4. Hesaplamayı yapın ve atayın gbSize.

Adım 3, sadece bir değişken tahsis etmekten çok daha pahalıdır. Üstelik bunu beş kez her ikisi için iki kez olmak üzere, GBve MB. Bunları işlevin başlangıcında (ör. var gb = GB) Taklit ettiyseniz ve bunun yerine takma ada başvurduysanız, bazı JS motorlarının zaten bu optimizasyonu gerçekleştirmesi mümkün olsa da, aslında küçük bir hızlanma üreteceğinden şüpheleniyorum . Ve elbette, uygulamayı hızlandırmanın en etkili yolu, kapsam zincirini hiç geçmemek.

JavaScript'in, derleyicinin bu değişken adreslerini derleme zamanında çözdüğü, derlenmiş, statik olarak yazılmış bir dil gibi olmadığını unutmayın. JS motoru bunları ada göre çözümlemek zorundadır ve bu aramalar her seferinde çalışma zamanında gerçekleşir. Yani mümkün olduğunca onlardan kaçınmak istersiniz.

Değişken atama JavaScript'te son derece ucuzdur. Bu ifadeyi destekleyecek hiçbir şeyim olmamasına rağmen, aslında en ucuz işlem olabilir. Bununla birlikte, değişken oluşturmaktan kaçınmaya çalışmak neredeyse hiç iyi bir fikir olmadığını söylemek güvenlidir ; bu alanda yapmaya çalıştığınız neredeyse tüm optimizasyonlar aslında işleri daha da kötüleştirecek, performans açısından.

Bir örnek bir kapatma içerir, diğeri içermez. Kapanışları uygulamak biraz zordur, çünkü değişkenler üzerinde kapalı normal değişkenler gibi çalışmaz. Bu, C gibi düşük seviyeli bir dilde daha belirgindir, ancak bunu göstermek için JavaScript kullanacağım.

Bir kapatma sadece bir fonksiyondan ibaret değildir, aynı zamanda kapattığı tüm değişkenlerden de oluşur. Bu işlevi çağırmak istediğimizde, tüm kapalı değişkenleri de sağlamalıyız. Bir kapatmayı, bu kapalı değişkenleri temsil eden ilk argüman olarak bir nesne alan bir işlevle modelleyebiliriz:

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)Bunun gerektirdiği garip çağrı kuralına dikkat edin

JavaScript'in yerleşik nesne desteği, açık varsargümanı atlamayı mümkün kılar ve thisbunun yerine kullanmamıza izin verir :

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

Bu örnekler aslında kapanışları kullanan bu koda eşdeğerdir:

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

Bu son örnekte, nesne yalnızca döndürülen iki işlevi gruplamak için kullanılır; thisbağlayıcı ilgisi yoktur. Kapakların mümkün kılınmasıyla ilgili tüm detaylar - gizli verilerin gerçek fonksiyona aktarılması, kapanış değişkenlerine tüm erişimlerin bu gizli verilerdeki aramalara değiştirilmesi - dil tarafından halledilir.

Ancak, çağrıları kapatmak, bu ekstra veriyi geçme yükünü içerir ve bir kapatma çalışması, bu önbellek konumu ve normal değişkenlerle karşılaştırıldığında genellikle bir işaretçi dereference tarafından daha da kötüleştirilen ekstra verilerdeki aramaların yükünü içerir; kapaklara dayanmayan bir çözüm daha iyi performans gösterir. Özellikle kapanışınızın size kaydettiği her şey, ayrıştırma sırasında sabit katlanmış olabilecek birkaç son derece ucuz aritmetik işlem olduğundan.