v8 const, let ve var'ın JavaScript performans etkileri?

İşlevsel farklılıklardan bağımsız olarak, yeni anahtar kelimelerin 'izin ver' ve 'sabit' kullanımının performans üzerinde 'var'a göre genelleştirilmiş veya belirli bir etkisi var mı?

Programı çalıştırdıktan sonra:

function timeit(f, N, S) {
    var start, timeTaken;
    var stats = {min: 1e50, max: 0, N: 0, sum: 0, sqsum: 0};
    var i;
    for (i = 0; i < S; ++i) {
        start = Date.now();
        f(N);
        timeTaken = Date.now() - start;

        stats.min = Math.min(timeTaken, stats.min);
        stats.max = Math.max(timeTaken, stats.max);
        stats.sum += timeTaken;
        stats.sqsum += timeTaken * timeTaken;
        stats.N++
    }

    var mean = stats.sum / stats.N;
    var sqmean = stats.sqsum / stats.N;

    return {min: stats.min, max: stats.max, mean: mean, spread: Math.sqrt(sqmean - mean * mean)};
}

var variable1 = 10;
var variable2 = 10;
var variable3 = 10;
var variable4 = 10;
var variable5 = 10;
var variable6 = 10;
var variable7 = 10;
var variable8 = 10;
var variable9 = 10;
var variable10 = 10;

function varAccess(N) {
    var i, sum;
    for (i = 0; i < N; ++i) {
        sum += variable1;
        sum += variable2;
        sum += variable3;
        sum += variable4;
        sum += variable5;
        sum += variable6;
        sum += variable7;
        sum += variable8;
        sum += variable9;
        sum += variable10;
    }
    return sum;
}

const constant1 = 10;
const constant2 = 10;
const constant3 = 10;
const constant4 = 10;
const constant5 = 10;
const constant6 = 10;
const constant7 = 10;
const constant8 = 10;
const constant9 = 10;
const constant10 = 10;

function constAccess(N) {
    var i, sum;
    for (i = 0; i < N; ++i) {
        sum += constant1;
        sum += constant2;
        sum += constant3;
        sum += constant4;
        sum += constant5;
        sum += constant6;
        sum += constant7;
        sum += constant8;
        sum += constant9;
        sum += constant10;
    }
    return sum;
}


function control(N) {
    var i, sum;
    for (i = 0; i < N; ++i) {
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
        sum += 10;
    }
    return sum;
}

console.log("ctl = " + JSON.stringify(timeit(control, 10000000, 50)));
console.log("con = " + JSON.stringify(timeit(constAccess, 10000000, 50)));
console.log("var = " + JSON.stringify(timeit(varAccess, 10000000, 50)));

.. Sonuçlarım şöyleydi:

ctl = {"min":101,"max":117,"mean":108.34,"spread":4.145407097016924}
con = {"min":107,"max":572,"mean":435.7,"spread":169.4998820058587}
var = {"min":103,"max":608,"mean":439.82,"spread":176.44417700791374}

Bununla birlikte, burada belirtildiği gibi tartışma, belirli senaryolar altında performans farklılıkları için gerçek bir potansiyele işaret ediyor gibi görünüyor: https://esdiscuss.org/topic/performance-concern-with-let-const

TL; DR

Teorik olarak , bu döngünün optimize edilmemiş bir versiyonu:

for (let i = 0; i < 500; ++i) {
    doSomethingWith(i);
}

aşağıdakilerle aynı döngünün optimize edilmemiş bir sürümünden daha yavaş olabilir var:

for (var i = 0; i < 500; ++i) {
    doSomethingWith(i);
}

Bir nedeni farklı i değişken ile, her döngü tekrarında için oluşturulan let, oysa sadece bir tane var iolan var.

Buna karşı tartışmak , bir optimizasyon avantajı sunabilecek şekilde yalnızca döngü içinde bildirilirken var, döngü dışında bildirildiği için kaldırıldığı gerçeğidir let.

Pratikte , 2018'de burada, modern JavaScript motorları, bu farkı ne zaman optimize edebileceğini bilmek için döngünün yeterince iç gözlemini yapıyor. (O zamandan önce bile, letdöngünüzün fazladan ilgili ek yükün yine de ortadan kalkmasına neden olacak kadar çalışması muhtemeldir. Ama şimdi bunun için endişelenmenize gerek yok.)

Yanlış anlaşılmaları son derece kolay olduğundan sentetik karşılaştırmalara dikkat edin ve JavaScript motoru optimize edicileri gerçek kodun yapmadığı şekillerde (hem iyi hem de kötü yollarla) tetikleyin. Bununla birlikte, sentetik bir kıyaslama istiyorsanız, işte bir tane:

const now = typeof performance === "object" && performance.now
    ? performance.now.bind(performance)
    : Date.now.bind(Date);

const btn = document.getElementById("btn");
btn.addEventListener("click", function() {
    btn.disabled = true;
    runTest();
});

const maxTests = 100;
const loopLimit = 50000000;
const expectedX = 1249999975000000;

function runTest(index = 1, results = {usingVar: 0, usingLet: 0}) {
    console.log(`Running Test #${index} of ${maxTests}`);
    setTimeout(() => {
        const varTime = usingVar();
        const letTime = usingLet();
        results.usingVar += varTime;
        results.usingLet += letTime;
        console.log(`Test ${index}: var = ${varTime}ms, let = ${letTime}ms`);
        ++index;
        if (index <= maxTests) {
            setTimeout(() => runTest(index, results), 0);
        } else {
            console.log(`Average time with var: ${(results.usingVar / maxTests).toFixed(2)}ms`);
            console.log(`Average time with let: ${(results.usingLet / maxTests).toFixed(2)}ms`);
            btn.disabled = false;
        }
    }, 0);
}

function usingVar() {
    const start = now();
    let x = 0;
    for (var i = 0; i < loopLimit; i++) {
        x += i;
    }
    if (x !== expectedX) {
        throw new Error("Error in test");
    }
    return now() - start;
}

function usingLet() {
    const start = now();
    let x = 0;
    for (let i = 0; i < loopLimit; i++) {
        x += i;
    }
    if (x !== expectedX) {
        throw new Error("Error in test");
    }
    return now() - start;
}

<input id="btn" type="button" value="Start">

V8 / Chrome veya SpiderMonkey / Firefox'taki bu sentetik testte önemli bir fark olmadığını söylüyor. (Her iki tarayıcıda da tekrarlanan testlerde bir kazanan veya diğeri kazanır ve her iki durumda da bir hata marjı dahilindedir.) Ama yine, bu sizin kodunuz değil, sentetik bir kıyaslamadır. Kodunuzda bir performans sorunu olduğunda ve eğer kodunuzun performansından endişe edin.

Bir stil meselesi olarak, letbir kapanışta döngü değişkenini kullanırsam kapsam belirleme avantajını tercih ederim ve döngülerde kapanma fayda sağlar.

Detaylar

Bir döngü arasındaki varve letiçindeki önemli fark , her yineleme için forfarklı bir döngü ioluşturulmasıdır; klasik "döngüdeki kapanışlar" sorununu ele alır:

function usingVar() {
  for (var i = 0; i < 3; ++i) {
    setTimeout(function() {
      console.log("var's i: " + i);
    }, 0);
  }
}
function usingLet() {
  for (let i = 0; i < 3; ++i) {
    setTimeout(function() {
      console.log("let's i: " + i);
    }, 0);
  }
}
usingVar();
setTimeout(usingLet, 20);

Her döngü gövdesi ( özellik bağlantısı ) için yeni EnvironmentRecord oluşturmak bir iştir ve çalışma zaman alır, bu nedenle teoride letsürüm sürümden daha yavaştır var.

Ancak, iyukarıdaki runnable snippet örneğinde yaptığım gibi, yalnızca, kullanan döngü içinde bir işlev (kapatma) oluşturduğunuzda fark önemlidir . Aksi takdirde, ayrım gözlenemez ve optimize edilebilir.

Burada 2018'de, V8 (ve Firefox'taki SpiderMonkey), letyineleme başına değişken semantiğini kullanmayan bir döngüde performans maliyeti olmadığına dair yeterli iç gözlem yapıyor gibi görünüyor . Bu testi görün .

Bazı durumlarda, özellikle genel değişkenler için, constsağlamayan bir optimizasyon fırsatı sağlayabilir var.

Küresel değişkenle ilgili sorun, küresel olmasıdır; Herhangi kod yerde bu erişebilir. Bu nedenle, varasla değiştirmek istemediğiniz (ve kodunuzda hiçbir zaman değişiklik yapmadığınız) bir değişken bildirirseniz, motor daha sonra yüklenen veya benzeri bir kodun sonucu olarak bunun asla değişmeyeceğini varsayamaz.

Bununla birlikte const, motora açıkça değerin değiştirilemeyeceğini söylüyorsunuz¹. Dolayısıyla, değerlerin değiştirilemeyeceğini bilerek, onu kullanan koda bir değişken referansı yerine bir hazır bilgi yaymak da dahil olmak üzere, istediği herhangi bir optimizasyonu yapmakta serbesttir.

¹ Nesnelerde değerin nesneye değil, nesneye bir referans olduğunu unutmayın. Böylece const o = {}, nesnenin ( o.answer = 42) durumunu değiştirebilirsiniz , ancak oyeni bir nesneye işaret edemezsiniz (çünkü bu, içerdiği nesne referansının değiştirilmesini gerektirir).

Kullanırken letveya constdiğer varbenzeri durumlarda, farklı performans göstermeleri olası değildir. Kullanmak ister Bu fonksiyon aynı performansa sahip olmalıdır varveya letörneğin:

function foo() {
    var i = 0;
    while (Math.random() < 0.5) {
        ++i;
    }
    return i;
}

Elbette hepsi önemli değildir ve yalnızca çözülmesi gereken gerçek bir sorun olduğunda endişelenecek bir şey vardır.

DÖNGÜ BEYANLARINDA "LET" DAHA İYİ

Navigatörde basit bir testle (5 kez) şöyle:

// WITH VAR
console.time("var-time")
for(var i = 0; i < 500000; i++){}
console.timeEnd("var-time")

Ortalama yürütme süresi 2,5 ms'den fazladır

// WITH LET
console.time("let-time")
for(let i = 0; i < 500000; i++){}
console.timeEnd("let-time")

Ortalama yürütme süresi 1,5 ms'den fazladır

Let ile döngü süresinin daha iyi olduğunu buldum.

TJ Crowder'ın cevabı çok mükemmel.

İşte bir ek: "Mevcut değişken bildirimlerini const olarak düzenlerken paranın karşılığını en çok ne zaman alırım?"

En fazla performans artışının "dışa aktarılan" işlevlerle ilgisi olduğunu buldum.

Dolayısıyla, A, B, R ve Z dosyası, U dosyasında, uygulamanız aracılığıyla yaygın olarak kullanılan bir "yardımcı program" işlevini çağırıyorsa, bu yardımcı program işlevini "const" olarak ve bir sabit dosyaya üst dosya başvurusu değiştirebilir bazı iyileştirilmiş performans. Bana göre ölçülebilir derecede daha hızlı değildi, ancak genel bellek tüketimi, büyük ölçüde monolitik Frankenstein-ed uygulamam için yaklaşık% 1-3 oranında azaldı. Eğer bulutta veya baremetal sunucunuzda çantalar dolusu nakit harcıyorsanız, bu değişken beyanlarından bazılarını taramak ve güncellemek için 30 dakika harcamak iyi bir neden olabilir.

Const, var ve kapakların nasıl çalıştığını okursanız, muhtemelen yukarıdakileri zaten bitirmişsinizdir ... ama "göz attığınızda": D.

Güncellemeyi yaptığım zaman v8.12.0 düğümündeki karşılaştırmadan hatırladığım kadarıyla, uygulamam boşta ~ 240MB RAM'den ~ 233MB RAM'e geçti.

TJ Crowder'ın cevabı çok iyi ama:

1. 'Let', kodu daha güçlü değil, daha okunaklı hale getirmek için yapılmıştır
2. teoriye göre var daha yavaş olur
3. uygulama ile derleyici tamamlanmamış bir programı tamamen (statik analiz) çözemez, dolayısıyla bazen optimizasyonu kaçırır
4. her durumda 'let' kullanmak iç gözlem için daha fazla CPU gerektirir, google v8 ayrıştırmaya başladığında tezgah başlatılmalıdır
5. iç gözlem başarısız olursa 'izin ver', V8 çöp toplayıcısını zorlar, serbest bırakmak / yeniden kullanmak için daha fazla yineleme gerektirir. ayrıca daha fazla RAM tüketecektir. yedek kulübesi bu noktaları dikkate almalıdır
6. Google Closure let in değişkenini dönüştürecek ...

Var ve let arasındaki performans boşluğunun etkisi, tek bir temel döngüde değil, gerçek hayattaki tam programda görülebilir.

Her neyse, gerek duymadığınız yerde let'i kullanmak, kodunuzu daha az okunabilir hale getirir.