Bunlar kazabildiğim detaylar. JavaScript'in genellikle bir VM üzerinde yorumlandığı ve çalıştırıldığı düşünülse de, kaynağı doğrudan makine koduna (IE hariç) derleme eğiliminde olan modern tercümanlarda durum böyle değildir.
Krom: V8 Motoru
V8'in bir derleme önbelleği var. Bu, derlenmiş JavaScript'i en fazla 5 çöp toplama kaynağı için bir karma kullanarak depolar. Bu, iki özdeş kaynak kodunun nasıl dahil edildiklerine bakılmaksızın bellekte bir önbellek girdisini paylaşacağı anlamına gelir. Sayfalar yeniden yüklendiğinde bu önbellek temizlenmez.
Kaynak
Güncelleme - 19/03/2015
Chrome ekibi, JavaScript akışı ve önbelleğe alma için yeni teknikleriyle ilgili ayrıntıları yayınladı .
- Script Akışı
Komut dosyası akışı, JavaScript dosyalarının ayrıştırılmasını optimize eder. [...]
Sürüm 41'den itibaren Chrome, indirme başlar başlamaz senkronize olmayan komutları ve ertelenen komut dosyalarını ayrı bir iş parçacığında ayrıştırır. Bu, ayrıştırmanın indirme işlemi bittikten sadece milisaniye sonra tamamlanabileceği ve sayfaların% 10 daha hızlı yüklenmesine neden olacağı anlamına gelir.
- Kod önbellekleme
Normalde, V8 motoru her ziyarette sayfanın JavaScript'ini derleyerek bir işlemcinin anladığı talimatlara dönüştürür. Derlenmiş kod derleme zamanında makinenin durumuna ve içeriğine büyük ölçüde bağımlı olduğundan, bu derlenmiş kod daha sonra kullanıcı sayfadan ayrıldığında atılır.
Chrome 42, derlenen kodun yerel bir kopyasını saklamak için gelişmiş bir teknik sunar, böylece kullanıcı sayfaya geri döndüğünde indirme, ayrıştırma ve derleme adımlarının tümü atlanabilir. Tüm sayfa yüklemelerinde bu, Chrome'un derleme süresinin yaklaşık% 40'ını önlemesine olanak tanır ve mobil cihazlarda değerli pil tasarrufu sağlar.
Opera: Carakan Engine
Uygulamada bu, bir kod programı derlenmek üzereyken, kaynak kodu yakın zamanda derlenen başka bir programla aynı olduğunda, derleyiciden önceki çıktıyı yeniden kullandığımız ve derleme adımını tamamen atladığımız anlamına gelir. Bu önbellek, bir sayfanın bir haber servisinden farklı haber makaleleri gibi sayfalar sonradan yüklendiği tipik tarama senaryolarında oldukça etkilidir, çünkü her sayfa genellikle aynı, bazen çok büyük komut dosyası kitaplığını yükler.
Bu nedenle, JavaScript sayfa yeniden yüklemelerinde önbelleğe alınır, aynı komut dosyasına yapılan iki istek yeniden derlemeye neden olmaz.
Kaynak
Firefox: SpiderMonkey Motoru
SpiderMonkey Nanojitbir JIT derleyicisi olan yerel arka ucu olarak kullanır . Makine kodunu derleme işlemi burada görülebilir . Kısacası, komut dosyaları yüklenirken yeniden derleniyor gibi görünüyor . Bununla birlikte, iç kısımlara daha yakından bakarsak , derlemeyi izlemek için kullanılan Nanojityüksek seviye monitörün jstracerderleme sırasında üç aşamadan geçebileceğini ve bunun bir fayda sağladığını görüyoruz Nanojit:
İzleme izleyicisinin başlangıç durumu izlemedir. Bu, spidermonkey'in bayt kodunu yorumladığı anlamına gelir. Spidermonkey geri atlama bayt kodunu her yorumladığında, monitör atlama hedefi program sayacı (PC) değerinin kaç defa atlandığını not eder. Bu numaraya PC için isabet sayısı denir. Belirli bir bilgisayarın vuruş sayısı bir eşik değerine ulaşırsa, hedef sıcak kabul edilir.
Monitör bir hedef PC'nin sıcak olduğuna karar verdiğinde, o hedef PC için yerel kod tutan bir parça olup olmadığını görmek için bir karma karmaşasına bakar. Böyle bir parça bulursa, çalışma moduna geçer. Aksi takdirde kayıt moduna geçer.
Bu hot, kod parçaları için yerel kodun önbelleğe alındığı anlamına gelir . Yeniden derlenmesi gerekmeyeceği anlamına gelir. Bu karma yerel bölümlerin sayfa yenilemeleri arasında tutulduğu açık değildir. Ama öyle olduklarını varsayıyorum. Herkes bunun için destekleyici kanıt bulabilirse o zaman mükemmel.
DÜZENLEME : Mozilla geliştiricisi Boris Zbarsky'nin Gecko'nun derlenmiş komut dosyalarını henüz önbelleğe almadığını belirtti . Alındığı bu SO cevap .
Safari: JavaScriptCore / SquirelFish Motoru
Bu uygulama için en iyi cevabın zaten başka biri tarafından verildiğini düşünüyorum .
Şu anda bayt kodunu (veya yerel kodu) önbelleğe almıyoruz.
Ancak, şu anda, kod oluşturma
JS yürütme süresinin önemsiz bir kısmı (<% 2) olduğunu düşündüğümüz bir seçenektir , bu yüzden
şu anda bunu takip etmiyoruz .
Bu, Safari'nin baş geliştiricisi Maciej Stachowiak tarafından yazılmıştır . Bence bunu doğru olarak kabul edebiliriz.
Ben başka bir bilgi bulamadı ancak en son hızı geliştirmeler hakkında daha fazla bilgi bulabilirsiniz SquirrelFish Extrememotor burada veya kaynak kodunu taramak burada maceracı hissediyorsanız.
IE: Çakra Motoru
Bu alanda IE9'un JavaScript Motoru (Çakra) hakkında güncel bilgi bulunmamaktadır. Eğer bir şey bilen varsa, lütfen yorum yap.
Bu oldukça gayri resmi olmakla IE eski motor uygulamaları için Eric Lippert ( JScript MS Geliştirici ) bir blog cevapta devletler burada o:
JScript Classic, herhangi bir JScript Classic programı çalıştırmadan önce kodu tam olarak kontrol ettiğimiz, tam ayrıştırma ağacı oluşturduğumuz ve bir bayt kodu oluşturduğumuz için derlenmiş bir dil gibi davranır. Ardından bayt kodunu bir bayt kodu yorumlayıcısı aracılığıyla çalıştırırız. Bu anlamda, JScript her bit Java kadar "derlenir". Aradaki fark, JScript'in tescilli bayt kodumuzu sürdürmenize veya incelemenize izin vermemesidir . Ayrıca, bayt kodu JVM bayt kodundan çok daha üst seviyededir - JScript Klasik bayt kodu dili ayrıştırma ağacının doğrusallaştırılmasından biraz daha fazladır, oysa JVM bayt kodu açıkça düşük seviyeli bir yığın makinesinde çalışacak şekilde tasarlanmıştır.
Bu, bayt kodunun hiçbir şekilde devam etmediğini ve dolayısıyla bayt kodunun önbelleğe alınmadığını gösterir.