Đây là những chi tiết mà tôi đã có thể đào lên. Điều đáng chú ý đầu tiên là mặc dù JavaScript thường được coi là được giải thích và chạy trên máy ảo, nhưng điều này thực sự không đúng với các trình thông dịch hiện đại, có xu hướng biên dịch nguồn trực tiếp thành mã máy (ngoại trừ IE).
Chrome: Động cơ V8
V8 có bộ đệm tổng hợp. Cửa hàng này đã biên dịch JavaScript bằng cách sử dụng hàm băm của nguồn cho tối đa 5 bộ sưu tập rác. Điều này có nghĩa là hai đoạn mã nguồn giống hệt nhau sẽ chia sẻ một mục bộ đệm trong bộ nhớ bất kể chúng được bao gồm như thế nào. Bộ đệm này không bị xóa khi các trang được tải lại.
Nguồn
Cập nhật - 19/03/2015
Nhóm Chrome đã phát hành chi tiết về các kỹ thuật mới của họ để phát trực tuyến và bộ đệm ẩn JavaScript .
- Tập lệnh truyền phát
Script streaming tối ưu hóa việc phân tích cú pháp các tệp JavaScript. [...]
Bắt đầu từ phiên bản 41, Chrome phân tích cú pháp async và hoãn lại các tập lệnh trên một luồng riêng biệt ngay khi quá trình tải xuống bắt đầu. Điều này có nghĩa là phân tích cú pháp có thể hoàn thành chỉ một phần nghìn giây sau khi quá trình tải xuống kết thúc và kết quả là các trang tải nhanh hơn 10%.
- Bộ nhớ đệm mã
Thông thường, công cụ V8 biên dịch JavaScript của trang mỗi lần truy cập, biến nó thành hướng dẫn mà bộ xử lý hiểu. Mã được biên dịch này sau đó sẽ bị loại bỏ khi người dùng điều hướng khỏi trang vì mã được biên dịch phụ thuộc nhiều vào trạng thái và ngữ cảnh của máy tại thời điểm biên dịch.
Chrome 42 giới thiệu một kỹ thuật nâng cao về lưu trữ bản sao mã được biên dịch cục bộ để khi người dùng quay lại trang, các bước tải xuống, phân tích cú pháp và biên dịch đều có thể được bỏ qua. Trên tất cả các lần tải trang, điều này cho phép Chrome tránh khoảng 40% thời gian biên dịch và tiết kiệm pin quý giá trên thiết bị di động.
Opera: Động cơ Carakan
Trong thực tế, điều này có nghĩa là bất cứ khi nào một chương trình tập lệnh sắp được biên dịch, có mã nguồn giống với chương trình khác đã được biên dịch gần đây, chúng tôi sử dụng lại đầu ra trước đó từ trình biên dịch và bỏ qua hoàn toàn bước biên dịch. Bộ đệm này khá hiệu quả trong các tình huống duyệt web điển hình trong đó một trang tải trang sau trang từ cùng một trang, chẳng hạn như các bài báo khác nhau từ một dịch vụ tin tức, vì mỗi trang thường tải cùng một thư viện tập lệnh, đôi khi rất lớn.
Do đó, JavaScript được lưu trữ trên các trang tải lại, hai yêu cầu cho cùng một tập lệnh sẽ không dẫn đến việc biên dịch lại.
Nguồn
Firefox: Công cụ SpiderMonkey
SpiderMonkey sử dụng Nanojitlàm back-end gốc, trình biên dịch JIT. Quá trình biên dịch mã máy có thể xem tại đây . Nói tóm lại, nó xuất hiện để biên dịch lại các tập lệnh khi chúng được tải. Tuy nhiên, nếu chúng ta xem xét kỹ hơn các phần bên trong, Nanojitchúng ta sẽ thấy rằng trình giám sát cấp cao hơn jstracer, được sử dụng để theo dõi quá trình biên dịch có thể chuyển qua ba giai đoạn trong quá trình biên dịch, mang lại lợi ích cho Nanojit:
Trạng thái ban đầu của màn hình theo dõi là giám sát. Điều này có nghĩa là spidermonkey đang diễn giải mã byte. Mỗi khi spidermonkey diễn giải mã byte nhảy lùi, màn hình sẽ ghi chú số lần giá trị bộ đếm chương trình đích (PC) đã được nhảy lên. Con số này được gọi là số lần truy cập cho PC. Nếu số lần truy cập của một PC cụ thể đạt đến giá trị ngưỡng, mục tiêu được coi là nóng.
Khi màn hình quyết định một PC mục tiêu đang nóng, nó sẽ tìm kiếm một đoạn mã băm để xem liệu có một đoạn nào giữ mã riêng cho PC đích đó hay không. Nếu nó tìm thấy một đoạn như vậy, nó chuyển sang chế độ thực thi. Nếu không, nó chuyển sang chế độ ghi.
Điều này có nghĩa là đối với hotcác đoạn mã, mã gốc được lưu trữ. Có nghĩa là sẽ không cần phải biên dịch lại. Điều không rõ ràng là các phần gốc được băm này được giữ lại giữa các lần làm mới trang. Nhưng tôi sẽ cho rằng họ là. Nếu ai có thể tìm thấy bằng chứng hỗ trợ cho điều này thì tuyệt vời.
EDIT : Nó được chỉ ra rằng nhà phát triển Mozilla Boris Zbarsky đã tuyên bố rằng Gecko không nhớ cache biên soạn kịch bản chưa . Lấy từ câu trả lời SO này .
Safari: JavaScriptCore / SquirelFish Engine
Tôi nghĩ rằng câu trả lời tốt nhất cho việc thực hiện này đã được đưa ra bởi người khác .
Hiện tại chúng tôi không lưu bộ đệm mã byte (hoặc mã gốc). Đó là một
tùy chọn mà chúng tôi đã xem xét, tuy nhiên, hiện tại, việc tạo mã là một
phần không đáng kể trong thời gian thực hiện JS (<2%), vì vậy chúng tôi hiện không theo đuổi
điều này.
Điều này được viết bởi Maciej Stachowiak , nhà phát triển chính của Safari. Vì vậy, tôi nghĩ rằng chúng ta có thể coi điều đó là đúng.
Tôi không thể tìm thấy bất kỳ thông tin nào khác nhưng bạn có thể đọc thêm về các cải tiến tốc độ của SquirrelFish Extremecông cụ mới nhất tại đây hoặc duyệt mã nguồn ở đây nếu bạn cảm thấy phiêu lưu.
IE: Công cụ Luân xa
Không có thông tin hiện tại nào liên quan đến Công cụ JavaScript (Chakra) của IE9 trong lĩnh vực này. Nếu ai biết bất cứ điều gì, xin vui lòng bình luận.
Điều này khá không chính thức, nhưng đối với việc triển khai công cụ cũ hơn của IE, Eric Lippert ( một nhà phát triển MS của JScript ) nói trong một bài trả lời blog ở đây rằng:
JScript Classic hoạt động giống như một ngôn ngữ được biên dịch theo nghĩa là trước khi bất kỳ chương trình JScript Classic nào chạy, chúng tôi hoàn toàn kiểm tra cú pháp mã, tạo một cây phân tích đầy đủ và tạo mã byte. Sau đó, chúng tôi chạy mã byte thông qua trình thông dịch mã byte. Theo nghĩa đó, JScript là mỗi bit được "biên dịch" như Java. Sự khác biệt là JScript không cho phép bạn kiên trì hoặc kiểm tra mã byte độc quyền của chúng tôi . Ngoài ra, mã byte là cấp độ cao hơn nhiều so với mã byte JVM - ngôn ngữ mã byte JScript Classic ít hơn một tuyến tính của cây phân tích cú pháp, trong khi mã byte JVM rõ ràng được dự định hoạt động trên máy ngăn xếp mức thấp.
Điều này cho thấy rằng mã byte không tồn tại theo bất kỳ cách nào và do đó mã byte không được lưu trữ.