소개
다니엘 클리포드는 Google I/O에서 V8의 JavaScript 성능을 개선하는 도움말과 유용한 정보에 관한 훌륭한 강연을 진행했습니다. 다니엘은 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] 할당으로 인해 배열이 언박싱된 double 배열로 변환되지만, a[3] 할당으로 인해 모든 값(숫자 또는 객체)을 포함할 수 있는 배열로 다시 변환되기 때문입니다. 두 번째 경우 컴파일러는 리터럴에 있는 모든 요소의 유형을 알고 있으며 숨겨진 클래스를 미리 결정할 수 있습니다.
- 크기가 고정된 작은 배열에 배열 리터럴을 사용하여 초기화
- 작은 배열(<64k)을 사용하기 전에 올바른 크기로 미리 할당
- 숫자 배열에 숫자가 아닌 값(객체)을 저장하지 않습니다.
- 리터럴 없이 초기화하는 경우 작은 배열이 다시 변환되지 않도록 주의하세요.
자바스크립트 컴파일
JavaScript는 매우 동적인 언어이며 원래 구현은 인터프리터였지만 최신 JavaScript 런타임 엔진은 컴파일을 사용합니다. V8(Chrome의 JavaScript)에는 실제로 두 가지 JIT(Just-In-Time) 컴파일러가 있습니다.
- 모든 JavaScript에 대해 양질의 코드를 생성할 수 있는 '전체' 컴파일러
- 최적화 컴파일러는 대부분의 JavaScript에 적합한 코드를 생성하지만 컴파일하는 데 시간이 더 오래 걸립니다.
전체 컴파일러
V8에서 전체 컴파일러는 모든 코드에서 실행되며 가능한 한 빨리 코드를 실행하기 시작하여 훌륭하지는 않지만 괜찮은 코드를 빠르게 생성합니다. 이 컴파일러는 컴파일 시점에 유형에 대해 거의 아무것도 가정하지 않습니다. 변수의 유형이 런타임에 변경될 수 있고 변경될 것이라고 예상합니다. Full 컴파일러에서 생성된 코드는 인라인 캐시(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
(최적화된 함수의 이름을 표준 출력에 기록합니다.)
하지만 모든 함수를 최적화할 수 있는 것은 아닙니다. 일부 기능은 최적화 컴파일러가 특정 함수에서 실행되지 않도록 합니다('bail-out'). 특히 최적화 컴파일러는 현재 try {} catch {} 블록이 있는 함수에서 중단됩니다.
따라서
- try {} catch {} 블록이 있는 경우 성능에 민감한 코드를 중첩 함수에 넣습니다. ```js function perf_sensitive() { // Do performance-sensitive work here }
try { perf_sensitive() } catch (e) { // Handle exceptions here } ```
이 지침은 향후 최적화 컴파일러에서 try/catch 블록을 사용 설정함에 따라 변경될 수 있습니다. 위와 같이 d8과 함께 '--trace-opt' 옵션을 사용하여 최적화 컴파일러가 함수에서 어떻게 중단되는지 검사할 수 있습니다. 이를 통해 어떤 함수가 중단되었는지에 대한 자세한 정보를 얻을 수 있습니다.
d8 --trace-opt primes.js
최적화 해제
마지막으로, 이 컴파일러에서 수행하는 최적화는 추측에 기반하므로 때로는 작동하지 않아 취소되기도 합니다. '역최적화' 프로세스는 최적화된 코드를 버리고 '전체' 컴파일러 코드의 올바른 위치에서 실행을 재개합니다. 나중에 재최적화가 다시 트리거될 수 있지만 단기적으로는 실행 속도가 느려집니다. 특히 함수가 최적화된 후 변수의 숨겨진 클래스가 변경되면 이 최적화 해제가 발생합니다.
따라서
- 최적화 후 함수에서 숨겨진 클래스 변경 방지
다른 최적화와 마찬가지로 로깅 플래그를 사용하여 V8이 최적화를 취소해야 했던 함수의 로그를 가져올 수 있습니다.
d8 --trace-deopt primes.js
기타 V8 도구
참고로 시작 시 Chrome에 V8 추적 옵션을 전달할 수도 있습니다.
"/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 없음)로 줄인 다음 해당 측정항목을 사용하여 병목 현상을 찾아 중요한 병목 현상을 제거해야 합니다. 다니엘의 강연(및 이 도움말)이 V8에서 JavaScript를 실행하는 방식을 더 잘 이해하는 데 도움이 되기를 바랍니다. 하지만 자체 알고리즘을 최적화하는 데도 집중해야 합니다.