소개
다니엘 클리포드가 V8에서 JavaScript 성능을 개선하기 위한 팁과 요령에 관한 Google I/O 강연을 진행했습니다. 다니엘은 '더 빠른 속도를 요구'하라고 권장했습니다. 즉, C++와 JavaScript 간의 성능 차이를 신중하게 분석하고 JavaScript의 작동 방식을 염두에 두고 코드를 작성하라는 의미입니다. 이 도움말에는 다니엘의 강연에서 가장 중요한 사항이 요약되어 있으며, 실적 가이드가 변경될 때마다 이 도움말도 업데이트됩니다.
가장 중요한 조언
성능 관련 조언은 맥락에 맞게 제공하는 것이 중요합니다. 실적 관련 조언은 중독성이 있으며, 심층적인 조언에 먼저 집중하면 실제 문제에 집중하지 못하게 될 수 있습니다. 웹 애플리케이션의 성능을 전체적으로 고려해야 합니다. 이러한 성능 도움말에 집중하기 전에 PageSpeed와 같은 도구를 사용하여 코드를 분석하고 점수를 올려야 합니다. 이렇게 하면 시기상조의 최적화를 방지할 수 있습니다.
웹 애플리케이션에서 우수한 성능을 얻기 위한 가장 좋은 기본적인 조언은 다음과 같습니다.
- 문제가 생기거나 발견하기 전에 준비
- 그런 다음 문제의 핵심을 파악하고 이해합니다.
- 마지막으로 중요한 문제를 해결합니다.
이러한 단계를 완료하려면 V8이 JS를 최적화하는 방법을 이해하여 JS 런타임 설계를 고려하여 코드를 작성하는 것이 중요할 수 있습니다. 사용 가능한 도구와 이러한 도구가 어떻게 도움이 되는지 알아보는 것도 중요합니다. 다니엘은 강연에서 개발자 도구를 사용하는 방법을 자세히 설명합니다. 이 문서에서는 V8 엔진 설계의 가장 중요한 몇 가지 사항만 다룹니다.
이제 V8 도움말을 살펴보겠습니다.
숨겨진 수업
JavaScript에는 제한된 컴파일 시간 유형 정보가 있습니다. 유형은 런타임에 변경될 수 있으므로 컴파일 시간에 JS 유형을 추론하는 것은 비용이 많이 든다고 예상할 수 있습니다. 이로 인해 JavaScript 성능이 어떻게 C++에 가까워질 수 있는지 의문이 생길 수 있습니다. 그러나 V8에는 런타임 시 객체에 대해 내부적으로 생성된 숨겨진 유형이 있습니다. 그러면 동일한 숨겨진 클래스를 가진 객체가 동일한 최적화된 생성 코드를 사용할 수 있습니다.
예를 들면 다음과 같습니다.
function Point(x, y) {
this.x = x;
this.y = y;
}
var p1 = new Point(11, 22);
var p2 = new Point(33, 44);
// At this point, p1 and p2 have a shared hidden class
p2.z = 55;
// warning! p1 and p2 now have different hidden classes!```
객체 인스턴스 p2에 추가 멤버 '.z'가 추가될 때까지 p1과 p2는 내부적으로 동일한 숨겨진 클래스를 보유합니다. 따라서 V8은 p1 또는 p2를 조작하는 JavaScript 코드에 최적화된 단일 버전의 최적화된 어셈블리를 생성할 수 있습니다. 숨겨진 클래스의 편차를 많이 방지할수록 성능이 향상됩니다.
따라서
- 생성자 함수에서 모든 객체 멤버를 초기화합니다 (나중에 인스턴스의 유형이 변경되지 않도록).
- 항상 동일한 순서로 객체 멤버를 초기화합니다.
숫자
V8은 유형이 변경될 수 있는 경우 태그를 사용하여 값을 효율적으로 나타냅니다. V8은 사용하는 값에서 처리 중인 숫자 유형을 추론합니다. V8이 추론하면 이러한 유형이 동적으로 변경될 수 있기 때문에 태그를 사용하여 값을 효율적으로 나타냅니다. 그러나 이러한 유형 태그를 변경하려면 때때로 비용이 발생하므로 숫자 유형을 일관되게 사용하는 것이 가장 좋으며, 일반적으로 적절한 경우에는 31비트의 부호 있는 정수를 사용하는 것이 가장 좋습니다.
예를 들면 다음과 같습니다.
var i = 42; // this is a 31-bit signed integer
var j = 4.2; // this is a double-precision floating point number```
따라서
- 31비트 부호 있는 정수로 표현할 수 있는 숫자 값을 사용하는 것이 좋습니다.
배열
대규모의 희소 배열을 처리하기 위해 내부적으로 두 가지 유형의 배열 저장소가 있습니다.
- 빠른 요소: 소형 키 세트의 선형 저장소
- 사전 요소: 그렇지 않으면 테이블 저장소 해시
배열 저장소가 한 유형에서 다른 유형으로 전환되지 않도록 하는 것이 가장 좋습니다.
따라서
- 배열에 0에서 시작하는 연속 키 사용
- 대규모 배열 (예: 64K개 이상의 요소)을 최대 크기로 사전 할당하지 말고 진행하면서 늘리세요.
- 배열의 요소, 특히 숫자 배열의 요소를 삭제하지 마세요.
- 초기화되지 않았거나 삭제된 요소를 로드하지 마세요.
for (var b = 0; b < 10; b++) {
a[0] |= b; // Oh no!
}
//vs.
a = new Array();
a[0] = 0;
for (var b = 0; b < 10; b++) {
a[0] |= b; // Much better! 2x faster.
}
또한 double의 배열은 더 빠릅니다. 배열의 숨겨진 클래스는 요소 유형을 추적하고 double만 포함된 배열은 숨겨진 클래스 변경을 초래합니다. 그러나 배열을 부주의하게 조작하면 복싱 및 언박싱으로 인해 추가 작업이 발생할 수 있습니다 (예:
var a = new Array();
a[0] = 77; // Allocates
a[1] = 88;
a[2] = 0.5; // Allocates, converts
a[3] = true; // Allocates, converts```
는 다음보다 효율성이 떨어집니다.
var a = [77, 88, 0.5, true];
첫 번째 예에서 개별 할당이 차례로 실행되고 a[2]
을 할당하면 배열이 unboxed double의 배열로 변환되지만 a[3]
를 할당하면 배열이 모든 값 (숫자 또는 객체)을 포함할 수 있는 배열로 다시 변환되기 때문입니다. 두 번째 경우에는 컴파일러가 리터럴의 모든 요소의 유형을 알고 있으므로 숨겨진 클래스를 미리 결정할 수 있습니다.
- 고정된 작은 크기의 배열에 배열 리터럴을 사용하여 초기화
- 작은 배열(64k 미만)을 사용하기 전에 올바른 크기로 사전 할당
- 숫자가 아닌 값 (객체)을 숫자 배열에 저장하지 않음
- 리터럴 없이 초기화하는 경우 작은 배열이 다시 변환되지 않도록 주의하세요.
JavaScript 컴파일
JavaScript는 매우 동적인 언어이며 원래 구현은 인터프리터였지만, 최신 JavaScript 런타임 엔진은 컴파일을 사용합니다. V8 (Chrome의 JavaScript)에는 두 가지 JIT (Just-In-Time) 컴파일러가 있습니다.
- 모든 JavaScript에 적합한 코드를 생성할 수 있는 '전체' 컴파일러
- 최적화 컴파일러: 대부분의 JavaScript에 적합한 우수한 코드를 생성하지만 컴파일 시간이 더 오래 걸립니다.
전체 컴파일러
V8에서 전체 컴파일러는 모든 코드에서 실행되며 최대한 빨리 코드 실행을 시작하여 우수하지는 않지만 나쁘지 않은 코드를 빠르게 생성합니다. 이 컴파일러는 컴파일 시 유형에 관해 거의 아무것도 가정하지 않습니다. 런타임 시 변수 유형이 변경될 수 있다고 예상합니다. 전체 컴파일러에서 생성된 코드는 인라인 캐시 (IC)를 사용하여 프로그램이 실행되는 동안 유형에 관한 지식을 미세 조정하여 실시간으로 효율성을 개선합니다.
인라인 캐시의 목표는 작업에 관한 유형 종속 코드를 캐시하여 유형을 효율적으로 처리하는 것입니다. 코드가 실행되면 먼저 유형 가정을 검증한 다음 인라인 캐시를 사용하여 작업을 단축합니다. 그러나 이렇게 하면 여러 유형을 허용하는 작업의 성능이 저하됩니다.
따라서
- 다형식 작업보다 단형식 작업을 사용하는 것이 좋습니다.
입력의 숨겨진 클래스가 항상 동일한 경우 작업은 단형이며, 그렇지 않으면 다형성입니다. 즉, 일부 인수는 작업을 여러 번 호출할 때 유형이 변경될 수 있습니다. 예를 들어 이 예에서 두 번째 add() 호출은 다형성을 야기합니다.
function add(x, y) {
return x + y;
}
add(1, 2); // + in add is monomorphic
add("a", "b"); // + in add becomes polymorphic```
최적화 컴파일러
V8은 전체 컴파일러와 동시에 최적화 컴파일러로 '핫' 함수 (즉, 여러 번 실행되는 함수)를 다시 컴파일합니다. 이 컴파일러는 유형 피드백을 사용하여 컴파일된 코드를 더 빠르게 만듭니다. 실제로 방금 이야기한 IC에서 가져온 유형을 사용합니다.
최적화 컴파일러에서 연산은 추측적으로 인라인 처리됩니다 (호출되는 위치에 직접 배치됨). 이렇게 하면 실행 속도가 빨라지지만 (메모리 공간을 차지하면서) 다른 최적화도 가능해집니다. 모노모픽 함수와 생성자는 완전히 인라인 처리될 수 있습니다. 이것이 V8에서 모노모피즘이 좋은 이유 중 하나입니다.
V8 엔진의 독립형 'd8' 버전을 사용하여 최적화되는 항목을 로깅할 수 있습니다.
d8 --trace-opt primes.js
(이는 최적화된 함수의 이름을 stdout에 기록합니다.)
그러나 모든 함수를 최적화할 수 있는 것은 아닙니다. 일부 기능은 최적화 컴파일러가 특정 함수에서 실행되지 않도록 합니다('종료'). 특히 최적화 컴파일러는 현재 try {} catch {} 블록이 있는 함수에서 종료됩니다.
따라서
- try {} catch {} 블록이 있는 경우 성능에 민감한 코드를 중첩 함수에 배치합니다. ```js function perf_sensitive() { // 여기에서 성능에 민감한 작업 실행 }
try { perf_sensitive() } catch (e) { // 여기에서 예외 처리 } ```
최적화 컴파일러에서 try/catch 블록을 사용 설정하므로 향후 변경될 수 있습니다. 위와 같이 d8과 함께 '--trace-opt' 옵션을 사용하여 최적화 컴파일러가 함수를 종료하는 방식을 검사할 수 있습니다. 그러면 종료된 함수에 관한 자세한 정보를 확인할 수 있습니다.
d8 --trace-opt primes.js
역최적화
마지막으로 이 컴파일러에서 실행하는 최적화는 추측적입니다. 최적화가 제대로 작동하지 않는 경우 컴파일러는 중단합니다. '역최적화' 프로세스는 최적화된 코드를 삭제하고 '전체' 컴파일러 코드의 적절한 위치에서 실행을 재개합니다. 나중에 재최적화가 다시 트리거될 수 있지만 단기적으로는 실행 속도가 느려집니다. 특히 함수가 최적화된 후 변수의 숨겨진 클래스를 변경하면 이러한 비최적화가 발생합니다.
따라서
- 함수가 최적화된 후 숨겨진 클래스 변경사항 방지
다른 최적화와 마찬가지로 로깅 플래그를 사용하여 V8에서 최적화 해제해야 했던 함수의 로그를 가져올 수 있습니다.
d8 --trace-deopt primes.js
기타 V8 도구
시작 시 V8 추적 옵션을 Chrome에 전달할 수도 있습니다.
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --js-flags="--trace-opt --trace-deopt"```
개발자 도구 프로파일링을 사용하는 것 외에도 d8을 사용하여 프로파일링할 수도 있습니다.
% out/ia32.release/d8 primes.js --prof
이는 밀리초마다 샘플을 가져와 v8.log를 작성하는 내장 샘플링 프로파일러를 사용합니다.
요약
성능이 우수한 JavaScript를 빌드하기 위해 V8 엔진이 코드와 함께 작동하는 방식을 파악하고 이해하는 것이 중요합니다. 기본 조언은 다음과 같습니다.
- 문제가 발생하기 전에 준비하세요
- 그런 다음 문제의 핵심을 파악하고 이해합니다.
- 마지막으로 중요한 문제를 해결합니다.
즉, 먼저 PageSpeed와 같은 다른 도구를 사용하여 JavaScript에 문제가 있는지 확인해야 합니다. 측정항목을 수집하기 전에 순수 JavaScript(DOM 없음)로 줄인 다음 이러한 측정항목을 사용하여 병목 현상을 찾아 중요한 병목 현상을 제거합니다. Daniel의 이야기와 이 글이 V8이 JavaScript를 실행하는 방법을 더 잘 이해하는 데 도움이 되기를 바랍니다. 하지만 자신만의 알고리즘을 최적화하는 데에도 집중하세요!