브라우저는 모든 페이지 로드에서 자바스크립트를 구문 분석합니까?
브라우저(IE 및 Firefox)는 페이지가 새로 고쳐질 때마다 링크된 Javascript 파일을 구문 분석합니까?
그들은 파일을 캐시할 수 있기 때문에 매번 다운로드하려고 하지는 않을 것이지만, 각 페이지가 본질적으로 분리되어 있기 때문에 오래된 코드를 모두 해체하고 다시 구문 분석할 것으로 예상됩니다.
이것은 완벽하게 이해할 수 있지만 비효율적이지만, 현대의 브라우저가 사이트 내에서 구문 분석 단계를 피할 수 있을 만큼 영리한지 궁금합니다.저는 ExtJS나 jQuery 등과 같이 사이트에서 자바스크립트 라이브러리를 사용하는 경우를 생각하고 있습니다.
이것들이 제가 파헤칠 수 있었던 세부 사항들입니다.먼저 JavaScript는 일반적으로 VM에서 해석 및 실행되는 것으로 간주되지만 IE를 제외하고 소스를 직접 기계 코드로 컴파일하는 경향이 있는 최신 인터프리터의 경우에는 그렇지 않습니다.
크롬: V8 엔진
V8에는 컴파일 캐시가 있습니다.최대 5개의 가비지 컬렉션에 대해 소스의 해시를 사용하여 컴파일된 JavaScript를 저장합니다.즉, 동일한 두 개의 소스 코드 조각이 포함된 방식에 관계없이 메모리에서 캐시 항목을 공유합니다.페이지를 다시 로드할 때 이 캐시는 지워지지 않습니다.
업데이트 - 2015년 3월 19일
Chrome 팀은 JavaScript 스트리밍 및 캐싱에 대한 새로운 기술에 대한 세부 정보를 공개했습니다.
- 스크립트 스트리밍
스크립트 스트리밍은 JavaScript 파일의 구문 분석을 최적화합니다. [...]
버전 41부터 Chrome은 다운로드가 시작되자마자 별도의 스레드에서 비동기 및 지연 스크립트를 구문 분석합니다.즉, 다운로드가 완료된 후 몇 밀리초 만에 구문 분석을 완료할 수 있으며 페이지 로드 속도가 10% 빨라집니다.
- 코드 캐싱
일반적으로 V8 엔진은 방문할 때마다 페이지의 JavaScript를 컴파일하여 프로세서가 이해하는 명령어로 변환합니다.컴파일된 코드는 컴파일 시 시스템의 상태와 컨텍스트에 따라 크게 달라지므로 사용자가 페이지를 벗어나면 이 컴파일된 코드는 삭제됩니다.
Chrome 42는 컴파일된 코드의 로컬 복사본을 저장하는 고급 기술을 도입하여 사용자가 페이지로 돌아갈 때 다운로드, 구문 분석 및 컴파일 단계를 모두 건너뛸 수 있습니다.이를 통해 크롬은 모든 페이지 로드에서 컴파일 시간의 약 40%를 절약할 수 있으며 모바일 장치의 소중한 배터리를 절약할 수 있습니다.
오페라: 카라칸 엔진
실제로 이것은 소스 코드가 최근에 컴파일된 다른 프로그램의 소스 코드와 동일한 스크립트 프로그램이 컴파일되려고 할 때마다 컴파일러의 이전 출력을 재사용하고 컴파일 단계를 완전히 건너뜁니다.이 캐시는 각 페이지가 동일하고 때로는 매우 큰 스크립트 라이브러리를 로드하는 경우가 많기 때문에 뉴스 서비스의 다른 뉴스 기사와 같이 동일한 사이트에서 한 페이지씩 로드하는 일반적인 검색 시나리오에서 상당히 효과적입니다.
따라서 페이지를 다시 로드할 때 JavaScript가 캐시되므로 동일한 스크립트에 대한 두 번의 요청으로 인해 다시 컴파일되지 않습니다.
파이어폭스: 스파이더 몽키 엔진
는 더몽이사용키를 사용합니다.Nanojit네이티브 백엔드인 JIT 컴파일러로서.기계 코드를 컴파일하는 과정은 여기에서 확인할 수 있습니다.간단히 말해 스크립트가 로드될 때 스크립트를 다시 컴파일하는 것으로 나타납니다.하지만, 우리가 더 자세히 들여다본다면,Nanojit의 모니터를 볼 수 .jstracer컴파일을 추적하는 데 사용되는 것은 컴파일 중에 3단계로 전환될 수 있으며, 이는 다음과 같은 이점을 제공합니다.Nanojit:
추적 모니터의 초기 상태는 모니터링입니다.이것은 거미 원숭이가 바이트 코드를 해석하고 있다는 것을 의미합니다.스파이더 원숭이가 후진 점프 바이트 코드를 해석할 때마다 모니터는 점프 대상 프로그램 카운터(PC) 값이 점프된 횟수를 기록합니다.이 숫자를 PC의 히트 카운트라고 합니다.특정 PC의 적중 횟수가 임계값에 도달하면 대상이 핫한 것으로 간주됩니다.
모니터가 대상 PC가 핫하다고 판단하면 대상 PC에 대한 네이티브 코드를 포함하는 조각이 있는지 확인하기 위해 조각의 해시 테이블을 찾습니다.이러한 조각이 발견되면 실행 모드로 전환됩니다.그렇지 않으면 기록 모드로 전환됩니다.
이것은 다음과 같은 의미입니다.hot네이티브 코드가 캐시된 코드 조각입니다.다시 컴파일할 필요가 없다는 의미입니다.페이지를 새로 고치는 동안 해시된 기본 섹션이 유지되는지 여부는 명확하지 않습니다.하지만 저는 그들이 그렇다고 생각합니다.이것에 대한 증거를 찾을 수 있는 사람이 있다면 훌륭합니다.
편집: Mozilla 개발자 Boris Zbarsky는 Gecko가 컴파일된 스크립트를 아직 캐시하지 않는다고 언급했다고 지적했습니다.이 SO 답변에서 발췌했습니다.
Safari : JavaScript Core/SquirelFish 엔진
이 구현에 대한 최상의 답변은 이미 다른 사람이 제공한 것이라고 생각합니다.
현재 바이트 코드(또는 기본 코드)를 캐시하지 않습니다.그것은
우리가 고려한 옵션, 그러나, 현재, 코드 생성은
JS 실행 시간의 사소한 부분(<2%), 그래서 우리는 추구하지 않습니다.
지금 이 순간.
이것은 사파리의 수석 개발자인 Maciej Stachowiak에 의해 쓰여졌습니다.그래서 저는 우리가 그것을 사실로 받아들일 수 있다고 생각합니다.
다른 정보를 찾을 수는 없지만 최신 시스템의 속도 향상에 대해 자세히 알아볼 수 있습니다.SquirrelFish Extreme여기서 엔진을 사용하거나, 모험심이 있다면 여기서 소스 코드를 탐색하십시오.
IE: 차크라 엔진
이 분야에서는 IE9의 자바스크립트 엔진(Chakra)에 대한 최신 정보가 없습니다.아시는 분 있으면 댓글 달아주세요.
이것은 상당히 비공식적이지만 IE의 이전 엔진 구현에 대해 Eric Lippert(JScript의 MS 개발자)는 블로그 답변에서 다음과 같이 말합니다.
JScript Classic은 JScript Classic 프로그램이 실행되기 전에 코드를 완전히 구문 검사하고 전체 구문 분석 트리를 생성하고 바이트 코드를 생성한다는 점에서 컴파일된 언어처럼 작동합니다.그런 다음 바이트 코드 인터프리터를 통해 바이트 코드를 실행합니다.그런 의미에서 JScript는 Java만큼 "컴파일된" 것입니다.차이점은 JScript가 당사의 독점 바이트 코드를 유지하거나 검사할 수 없다는 것입니다.또한 JVM 바이트코드는 JVM 바이트코드보다 훨씬 더 높은 수준입니다. JScript Classic 바이트코드 언어는 구문 분석 트리의 선형화에 불과하지만 JVM 바이트코드는 분명히 낮은 수준의 스택 머신에서 작동하기 위한 것입니다.
이는 바이트 코드가 어떤 방식으로든 유지되지 않으므로 바이트 코드가 캐시되지 않음을 나타냅니다.
다른 답변에서 언급했듯이 오페라가 그것을 합니다. (출처)
Firefox(SpiderMonkey 엔진)는 바이트 코드를 캐시하지 않습니다.(소스)
WebKit(Safari, Konqueror)는 바이트 코드를 캐시하지 않습니다.(소스)
IE[6/7/8] 또는 V8(Chrome)에 대해서는 잘 모르겠습니다. IE는 캐싱을 수행할 수 있지만 V8은 캐싱을 수행하지 않을 수 있습니다.IE가 폐쇄 소스여서 잘 모르겠지만 V8에서는 "컴파일된" 코드를 기계 코드로 바로 컴파일하기 때문에 캐시하는 것이 말이 되지 않을 수 있습니다.
제가 알기로는 Opera만이 구문 분석된 JavaScript를 캐시합니다.여기에서 "캐시된 컴파일된 프로그램" 섹션을 참조하십시오.
Google Dart가 "스냅샷"을 통해 이 문제를 명시적으로 해결하는 것은 아무런 가치가 없습니다. 목표는 준비된 버전의 코드를 로드하여 초기화 및 로딩 시간을 단축하는 것입니다.
InfoQ는 http://www.infoq.com/articles/google-dart 에서 좋은 기록을 가지고 있습니다.
제 생각에 정답은 "항상 그렇지는 않습니다."라고 생각합니다.브라우저와 서버 모두 캐시할 항목을 결정하는 역할을 하는 것으로 알고 있습니다.매번 파일을 다시 로드해야 하는 경우 Apache 내에서 파일을 구성할 수 있어야 합니다(예:물론 사용자의 브라우저가 해당 설정을 무시하도록 구성될 수 있다고 생각하지만, 그럴 가능성은 거의 없습니다.
따라서 대부분의 실제적인 경우 자바스크립트 파일 자체가 캐시되긴 하지만 페이지가 로드될 때마다 동적으로 다시 해석됩니다.
브라우저는 분명히 캐싱을 사용하지만 예, 페이지가 새로 고쳐질 때마다 브라우저는 JavaScript를 구문 분석합니다.브라우저에서 페이지를 로드할 때마다 2개의 트리 1이 생성되기 때문입니다.내용 트리 및 2.렌더 트리.
이 렌더 트리는 돔 요소의 시각적 레이아웃에 대한 정보로 구성됩니다.따라서 페이지가 로드될 때마다 Javascript가 구문 분석되고 Javascript에 의한 동적 변경 사항은 돔 요소의 위치 지정, 요소 표시/숨기기, 요소 추가/제거와 같이 브라우저가 렌더 트리를 다시 생성하도록 합니다.그러나 FF와 크롬과 같은 현대의 브라더스는 이를 약간 다르게 처리하기 때문에 위에서 언급한 것과 같이 j에 의한 동적인 변화가 있을 때마다 해당 요소들이 렌더링되고 다시 칠하게 됩니다.
언급URL : https://stackoverflow.com/questions/1096907/do-browsers-parse-javascript-on-every-page-load
'programing' 카테고리의 다른 글
| 타자 스크립트를 사용하여 각도 2에서 장치 디스플레이의 높이와 너비를 얻는 방법은 무엇입니까? (0) | 2023.08.04 |
|---|---|
| 깃 클론:stdout으로 stderr 리디렉션하지만 오류는 stderr에 계속 기록됩니다. (0) | 2023.08.04 |
| iPhone Store Kit "iTunes Store에 연결할 수 없습니다" (0) | 2023.08.04 |
| 개체가 개체 목록에 있는지 확인합니다. (0) | 2023.08.04 |
| 배치 파일에서 호출할 때 PowerShell 스크립트가 고착되어 종료되지 않음 (0) | 2023.08.04 |