이것들은 내가 파낼 수 있었던 세부 사항입니다. JavaScript는 일반적으로 VM에서 해석되고 VM에서 실행되는 것으로 간주되지만 실제로는 소스를 기계 코드로 직접 컴파일하는 경향이있는 최신 인터프리터에서는 그렇지 않습니다 (IE 제외).
크롬 : V8 엔진
V8에는 컴파일 캐시가 있습니다. 최대 5 개의 가비지 콜렉션에 대한 소스 해시를 사용하여 컴파일 된 JavaScript를 저장합니다. 이는 두 개의 동일한 소스 코드 조각이 포함 된 방식에 관계없이 메모리에서 캐시 항목을 공유 함을 의미합니다. 이 캐시는 페이지를 다시로드 할 때 지워지지 않습니다.
출처
업데이트-2015 년 3 월 19 일
Chrome 팀은 JavaScript 스트리밍 및 캐싱을위한 새로운 기술에 대한 세부 정보를 발표 했습니다 .
- 스크립트 스트리밍
스크립트 스트리밍은 JavaScript 파일의 구문 분석을 최적화합니다. [...]
버전 41부터 Chrome은 다운로드가 시작되는 즉시 비동기 및 지연된 스크립트를 별도의 스레드에서 구문 분석합니다. 즉, 다운로드가 완료된 후 밀리 초 만에 파싱이 완료 될 수 있으며 페이지 로딩 속도가 10 % 빨라집니다.
- 코드 캐싱
일반적으로 V8 엔진은 방문 할 때마다 페이지의 JavaScript를 컴파일하여 프로세서가 이해하는 지침으로 바꿉니다. 컴파일 된 코드는 컴파일 타임에 머신의 상태와 컨텍스트에 크게 의존하므로 사용자가 페이지에서 벗어나면이 컴파일 된 코드는 삭제됩니다.
Chrome 42에는 컴파일 된 코드의 로컬 사본을 저장하는 고급 기술이 도입되어 사용자가 페이지로 돌아올 때 다운로드, 파싱 및 컴파일 단계를 모두 건너 뛸 수 있습니다. 모든 페이지로드에서 Chrome은 컴파일 시간의 약 40 %를 피하고 휴대 기기의 소중한 배터리를 절약 할 수 있습니다.
오페라 : Carakan Engine
실제로 이것은 소스 코드가 최근에 컴파일 된 다른 프로그램의 소스 코드와 동일한 스크립트 프로그램을 컴파일하려고 할 때마다 컴파일러의 이전 출력을 재사용하고 컴파일 단계를 완전히 건너 뜁니다. 이 캐시는 뉴스 서비스의 다른 뉴스 기사와 같이 동일한 사이트에서 페이지마다 페이지를로드하는 일반적인 브라우징 시나리오에서 매우 효과적입니다. 각 페이지는 종종 동일하거나 때로는 매우 큰 스크립트 라이브러리를로드하기 때문입니다.
따라서 JavaScript는 페이지를 다시로드 할 때 캐시되므로 동일한 스크립트에 대한 두 가지 요청은 다시 컴파일되지 않습니다.
출처
Firefox : SpiderMonkey 엔진
SpiderMonkey는 Nanojit기본 백엔드 인 JIT 컴파일러로 사용합니다. 머신 코드를 컴파일하는 과정은 여기에서 볼 수 있습니다 . 요컨대, 스크립트가로드되면 다시 컴파일 하는 것처럼 보입니다 . 그러나 내부를 자세히 살펴보면 컴파일을 추적하는 데 사용되는 Nanojit더 높은 수준의 모니터 jstracer가 컴파일 중 3 단계를 통해 전환 할 수 있으며 Nanojit다음과 같은 이점이 있습니다 .
추적 모니터의 초기 상태는 모니터링입니다. 이것은 spidermonkey가 바이트 코드를 해석하고 있음을 의미합니다. spidermonkey가 역방향 점프 바이트 코드를 해석 할 때마다 모니터는 점프 대상 프로그램 카운터 (PC) 값이 점프 한 횟수를 기록합니다. 이 숫자를 PC의 적중 횟수라고합니다. 특정 PC의 적중 횟수가 임계 값에 도달하면 대상이 핫한 것으로 간주됩니다.
모니터가 대상 PC가 뜨겁다 고 판단하면 해당 대상 PC에 대한 고유 코드를 보유하는 단편이 있는지 확인하기 위해 단편의 해시 테이블을 찾습니다. 그러한 조각을 찾으면 실행 모드로 전환됩니다. 그렇지 않으면 녹화 모드로 전환됩니다.
이는 hot코드 조각의 경우 기본 코드가 캐시 됨을 의미합니다 . 다시 컴파일 할 필요가 없다는 의미입니다. 해시 된 기본 섹션이 페이지 새로 고침 사이에 유지되는지는 확실하지 않습니다. 그러나 나는 그들이 있다고 가정합니다. 누구든지 이것에 대한 증거를 찾을 수 있다면 훌륭합니다.
편집 : 모질라 개발자 Boris Zbarsky는 Gecko가 컴파일 된 스크립트를 아직 캐시하지 않는다고 언급 한 것으로 알려졌습니다 . 이 SO 답변 에서 가져온 .
Safari : JavaScriptCore / SquirelFish 엔진
이 구현에 대한 최상의 답변은 이미 다른 사람에 의해 제공되었다고 생각합니다. .
우리는 현재 바이트 코드 (또는 네이티브 코드)를 캐시하지 않습니다. 그것은이입니다
우리가 고려한 옵션, 그러나, 현재, 코드 생성은이다
우리가 추구하지 않는, 그래서 JS 실행 시간 (<2 %)의 사소한 부분
순간이.
이것은 Maciej Stachowiak에 의해 작성되었습니다 Safari의 수석 개발자 인 . 그래서 우리는 그것을 사실로 받아 들일 수 있다고 생각합니다.
다른 정보를 찾을 수 없지만 최신 SquirrelFish Extreme엔진 의 속도 향상에 대한 자세한 내용은 여기 를 참조하거나 모험적인 느낌이 드는 경우 여기 에서 소스 코드를 찾아보십시오 .
IE : 차크라 엔진
이 필드에는 IE9의 JavaScript 엔진 (Chakra)에 관한 최신 정보가 없습니다. 누구든지 아는 것이 있으면 의견을 말하십시오.
이것은 비공식적이지만 IE의 오래된 엔진 구현의 경우 Eric Lippert ( JScript의 MS 개발자 )는 블로그에 다음과 같이 답변 합니다. 있다는 :
JScript Classic은 JScript Classic 프로그램이 실행되기 전에 코드를 완전히 구문 검사하고 전체 구문 분석 트리를 생성하며 바이트 코드를 생성한다는 점에서 컴파일 된 언어처럼 작동합니다. 그런 다음 바이트 코드 인터프리터를 통해 바이트 코드를 실행합니다. 그런 의미에서 JScript는 Java만큼 "컴파일 된"것입니다. 차이점은 JScript에서는 독점 바이트 코드를 유지하거나 검사 할 수 없다는 것 입니다. 또한 바이트 코드는 JVM 바이트 코드보다 훨씬 높은 수준입니다 .JScript Classic 바이트 코드 언어는 구문 분석 트리의 선형화에 지나지 않으며 JVM 바이트 코드는 분명히 저수준 스택 시스템에서 작동하도록 설계되었습니다.
이것은 바이트 코드가 어떤 식 으로든 지속되지 않으므로 바이트 코드가 캐시되지 않음을 나타냅니다.