นี่คือรายละเอียดที่ฉันสามารถขุดได้ เป็นสิ่งสำคัญที่ควรทราบก่อนถึงแม้ว่า JavaScript จะถูกตีความและเรียกใช้บน VM แต่นี่ไม่ใช่กรณีของล่ามที่ทันสมัยซึ่งมักจะรวบรวมแหล่งที่มาโดยตรงในรหัสเครื่อง (ยกเว้น IE)
Chrome: V8 Engine
V8 มีแคชรวบรวม การจัดเก็บนี้รวบรวม JavaScript โดยใช้แฮชของแหล่งที่มาสำหรับคอลเลกชันขยะสูงสุด 5 รายการ ซึ่งหมายความว่าซอร์สโค้ดสองชิ้นที่เหมือนกันจะแชร์รายการแคชในหน่วยความจำไม่ว่าจะรวมอยู่ในที่ใด แคชนี้ไม่ถูกล้างออกเมื่อทำการโหลดหน้าใหม่
แหล่ง
อัปเดต - 19/03/2015
ทีมงาน Chrome ได้เปิดเผยรายละเอียดเกี่ยวกับเทคนิคใหม่ของการสตรีมและการแคช JavaScriptแคช
- การสตรีมสคริปต์
การสตรีมสคริปต์เพิ่มประสิทธิภาพการแยกวิเคราะห์ไฟล์ JavaScript [ ... ]
เริ่มต้นในรุ่น 41 Chrome จะแยกวิเคราะห์ async และสคริปต์ที่เลื่อนออกไปบนเธรดแยกต่างหากทันทีที่การดาวน์โหลดเริ่มขึ้น ซึ่งหมายความว่าการวิเคราะห์คำสามารถเสร็จสมบูรณ์เพียงแค่มิลลิวินาทีหลังจากการดาวน์โหลดเสร็จสิ้นและส่งผลให้หน้าโหลดเร็วขึ้นมากถึง 10%
- การแคชรหัส
โดยปกติแล้วเครื่องยนต์ V8 จะรวบรวม JavaScript ของหน้าเว็บทุกครั้งที่เข้าชมโดยเปลี่ยนเป็นคำแนะนำที่โปรเซสเซอร์เข้าใจ รหัสที่คอมไพล์แล้วจะถูกยกเลิกเมื่อผู้ใช้นำทางออกจากหน้าเว็บเนื่องจากโค้ดที่รวบรวมนั้นขึ้นอยู่กับสถานะและบริบทของเครื่องในเวลารวบรวม
Chrome 42 แนะนำเทคนิคขั้นสูงในการจัดเก็บสำเนาของรหัสที่คอมไพล์ในเครื่องดังนั้นเมื่อผู้ใช้กลับไปที่หน้าการดาวน์โหลดการแยกวิเคราะห์และขั้นตอนการรวบรวมสามารถข้ามได้ ในการโหลดหน้าเว็บทั้งหมดนี้ทำให้ Chrome สามารถหลีกเลี่ยงการรวบรวมเวลาได้ 40% และประหยัดแบตเตอรี่ที่มีค่าบนอุปกรณ์มือถือ
Opera: Carakan Engine
ในทางปฏิบัตินี่หมายความว่าเมื่อใดก็ตามที่โปรแกรมสคริปต์กำลังจะรวบรวมซึ่งซอร์สโค้ดเหมือนกับโปรแกรมอื่น ๆ ที่เพิ่งถูกคอมไพล์เมื่อเร็ว ๆ นี้เราจะใช้เอาต์พุตก่อนหน้าจากคอมไพเลอร์และข้ามขั้นตอนการรวบรวมทั้งหมด แคชนี้ค่อนข้างมีประสิทธิภาพในสถานการณ์การสืบค้นทั่วไปซึ่งหนึ่งหน้าโหลดหน้าต่อจากหน้าเว็บไซต์เดียวกันเช่นบทความข่าวต่าง ๆ จากบริการข่าวเนื่องจากแต่ละหน้ามักจะโหลดเหมือนกันบางครั้งมีขนาดใหญ่มากห้องสมุดสคริปต์
ดังนั้น JavaScript ถูกแคชระหว่างการโหลดหน้าซ้ำสองคำขอไปยังสคริปต์เดียวกันจะไม่ส่งผลให้มีการรวบรวมใหม่
แหล่ง
Firefox: SpiderMonkey Engine
SpiderMonkey ใช้Nanojitเป็น back-end ดั้งเดิมของคอมไพเลอร์ JIT ขั้นตอนของการรวบรวมรหัสเครื่องที่สามารถมองเห็นได้ที่นี่ กล่าวโดยย่อดูเหมือนว่าจะคอมไพล์สคริปต์อีกครั้งขณะที่โหลด อย่างไรก็ตามถ้าเรามองลึกเข้าไปภายในของNanojitเราเห็นว่าจอภาพระดับสูงjstracerซึ่งใช้ในการติดตามการรวบรวมสามารถเปลี่ยนผ่านสามขั้นตอนในระหว่างการรวบรวมให้ประโยชน์Nanojit:
สถานะเริ่มต้นของการตรวจสอบติดตามคือการตรวจสอบ ซึ่งหมายความว่า spidermonkey กำลังตีความ bytecode ทุกครั้งที่ spidermonkey ตีความ bytecode ย้อนหลังกระโดดจอภาพจะบันทึกจำนวนครั้งที่ค่าโปรแกรมข้ามเคาน์เตอร์เป้าหมาย (PC) ถูกข้ามไปยัง หมายเลขนี้เรียกว่าจำนวนการเข้าชมสำหรับพีซี หากจำนวนการเข้าชมของพีซีใดเครื่องหนึ่งถึงค่าเกณฑ์เป้าหมายจะถือว่าร้อน
เมื่อจอภาพตัดสินพีซีเป้าหมายร้อนมันจะดูเป็นส่วนย่อยเพื่อดูว่ามีชิ้นส่วนที่ถือรหัสเนทีฟสำหรับพีซีเป้าหมายนั้นหรือไม่ หากพบชิ้นส่วนดังกล่าวจะเปลี่ยนเป็นโหมดการดำเนินการ มิฉะนั้นจะเปลี่ยนเป็นโหมดบันทึก
ซึ่งหมายความว่าสำหรับhotรหัสเศษเล็กเศษน้อยรหัสพื้นเมืองจะถูกแคช ความหมายที่ไม่จำเป็นต้องคอมไพล์ใหม่ ไม่ชัดเจนว่าส่วนที่ถูกแฮชแบบดั้งเดิมถูกเก็บไว้ระหว่างการรีเฟรชหน้าหรือไม่ แต่ฉันคิดว่าพวกเขาเป็นหากใครสามารถหาหลักฐานสนับสนุนสำหรับเรื่องนี้แล้วยอดเยี่ยม
แก้ไข : มันได้รับการชี้ให้เห็นว่านักพัฒนา Mozilla บอริส Zbarsky ได้กล่าวว่าตุ๊กแกไม่ได้รวบรวมแคชสคริปต์เลย นำมาจากคำตอบ SOนี้
Safari: JavaScriptCore / SquirelFish Engine
ฉันคิดว่าคำตอบที่ดีที่สุดสำหรับการติดตั้งใช้งานนี้ได้รับจากบุคคลอื่นแล้ว
ขณะนี้เราไม่ได้แคชไบต์ (หรือรหัสพื้นเมือง) มันเป็น
ตัวเลือกที่เราได้พิจารณาอย่างไรก็ตามในปัจจุบันการสร้างรหัสเป็น
ส่วนที่สำคัญของเวลาดำเนินการ JS (<2%) ดังนั้นเราจึงไม่ดำเนินการต่อ
นี้ในขณะนี้
สิ่งนี้เขียนโดยMaciej Stachowiakผู้นำการพัฒนาของ Safari ดังนั้นฉันคิดว่าเราสามารถเป็นจริงได้
ผมก็ไม่สามารถที่จะหาข้อมูลอื่น ๆ แต่คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการปรับปรุงความเร็วของล่าสุดของSquirrelFish Extremeเครื่องยนต์ที่นี่หรือเรียกดูรหัสที่มาที่นี่ถ้าคุณรู้สึกรักการผจญภัย
IE: Chakra Engine
ไม่มีข้อมูลปัจจุบันเกี่ยวกับ JavaScript Engine (Chakra) ของ IE9 ในด้านนี้ หากใครรู้อะไรกรุณาแสดงความคิดเห็น
นี่เป็นเรื่องที่ค่อนข้างไม่เป็นทางการ แต่สำหรับการใช้งานเครื่องมือรุ่นเก่าของ IE นั้น Eric Lippert ( ผู้พัฒนา MS ของ JScript ) ระบุไว้ในบล็อกตอบกลับที่นี่ว่า:
JScript Classic ทำหน้าที่เหมือนภาษาที่คอมไพล์ในแง่ที่ว่าก่อนที่โปรแกรม JScript Classic ใด ๆ จะทำงานเราจะตรวจสอบไวยากรณ์ทั้งหมดของโค้ดสร้างแผนผังการแยกแบบเต็มและสร้าง bytecode จากนั้นเราจะเรียกใช้ bytecode ผ่านล่าม bytecode ในแง่นั้น JScript นั้นเป็น "คอมไพล์" เหมือนกับ Java ความแตกต่างคือ JScript ไม่อนุญาตให้คุณยังคงมีอยู่หรือตรวจสอบ bytecode นอกจากนี้ bytecode ยังสูงกว่า JVM bytecode มาก - ภาษา JScript Classic bytecode นั้นเล็กไปกว่าการวางตัวเป็นแนวตรงของต้นไม้ในขณะที่ JVM bytecode นั้นมีจุดประสงค์ที่ชัดเจนในการใช้งานบนเครื่องสแต็กระดับต่ำ
สิ่งนี้ชี้ให้เห็นว่า bytecode ไม่คงอยู่ในลักษณะใด ๆ และทำให้ bytecode ไม่ถูกแคช