소개
다니엘 클리포드가 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]
의 할당으로 인해 배열이 unboxed double의 배열로 변환되지만 a[3]
를 할당하면 배열이 모든 값 (숫자 또는 객체)을 포함할 수 있는 배열로 다시 변환되기 때문입니다. 두 번째 경우 컴파일러는 리터럴에 있는 모든 요소의 유형을 알고 있으므로 숨겨진 클래스를 미리 결정할 수 있습니다.
- 크기가 고정된 작은 배열의 배열 리터럴을 사용하여 초기화
- 사용하기 전에 작은 배열(64k 미만)을 올바른 크기로 사전 할당
- 숫자가 아닌 값 (객체)을 숫자 배열에 저장하지 않음
- 리터럴 없이 초기화하는 경우 작은 배열이 다시 변환되지 않도록 주의하세요.
JavaScript 컴파일
JavaScript는 매우 동적인 언어이며 원래 구현은 인터프리터였지만, 최신 JavaScript 런타임 엔진에서는 컴파일을 사용합니다. V8 (Chrome의 JavaScript)에는 실제로 두 가지 JIT (Just-In-Time) 컴파일러가 있습니다.
- '전체' 모든 JavaScript에서 적합한 코드를 생성할 수 있는
- 최적화 컴파일러는 대부분의 자바스크립트에 적합한 코드를 생성하지만 컴파일하는 데 더 오래 걸립니다.
전체 컴파일러
V8에서는 Full 컴파일러가 모든 코드에서 실행되고 가능한 한 빨리 코드 실행을 시작하여 정상적이지만 좋지 않은 코드를 빠르게 생성합니다. 이 컴파일러는 컴파일 시 유형에 관해 거의 아무 것도 가정하지 않습니다. 변수 유형이 런타임에 변경될 수 있고 변경될 것으로 예상합니다. 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에서 단형성이 좋은 아이디어인 또 다른 이유입니다.
독립형 'd8'을 사용하여 최적화되는 항목을 기록할 수 있습니다. 버전:
d8 --trace-opt primes.js
(이는 최적화된 함수의 이름을 stdout에 기록합니다.)
그러나 모든 함수를 최적화할 수 있는 것은 아닙니다. 일부 기능은 최적화 컴파일러가 특정 함수에서 실행되지 못하도록 합니다('bail-out'). 특히, 최적화 컴파일러는 현재 try {} catch {} 블록을 포함하는 함수에 중점을 둡니다.
따라서
- {} catch {} 블록을 시도해 본 경우 성능에 민감한 코드를 중첩된 함수에 넣습니다. ```js function perf_sensitive() { // 여기에서 성능에 민감한 작업을 실행하세요. }
try { perf_sensitive() } catch (e) { // 여기에서 예외 처리 } ```
최적화 컴파일러에서 try/catch 블록을 사용 설정하므로 향후 변경될 수 있습니다. '--trace-opt' 옵션을 확인하여 어떤 함수가 제거되었는지에 대한 자세한 정보를 얻을 수 있습니다.
d8 --trace-opt primes.js
탈최적화
마지막으로, 이 컴파일러에 의해 수행되는 최적화는 추측적입니다. 때때로 제대로 작동하지 않아서 백화합니다. '탈최적화' 프로세스 최적화된 코드를 폐기하고 올바른 위치에서 실행을 'full'으로 재개 컴파일할 수 있습니다. 재최적화가 나중에 다시 트리거될 수 있지만 단기적으로는 실행 속도가 느려집니다. 특히 함수가 최적화된 후에 변수의 히든 클래스를 변경하면 이러한 탈최적화가 발생합니다.
따라서
- 최적화 후 함수에서 숨겨진 클래스 변경 방지
다른 최적화와 마찬가지로 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를 작성합니다.
요약
고성능 자바스크립트를 빌드하기 위해 V8 엔진이 코드와 어떻게 작동하는지 파악하고 이해하는 것이 중요합니다. 기본 조언은 다음과 같습니다.
- 문제가 발생하기 전에 (또는 알아차리기) 대비하기
- 그런 다음 문제의 핵심을 식별하고 이해합니다.
- 마지막으로, 중요한 문제 해결
즉, 먼저 PageSpeed와 같은 다른 도구를 사용하여 자바스크립트에 문제가 있는지 확인해야 합니다. 측정항목을 수집하기 전에 순수 자바스크립트 (DOM 아님)로 줄인 다음, 해당 측정항목을 사용하여 병목 현상을 찾고 중요한 항목을 제거할 수 있습니다. Daniel의 이야기와 이 글이 V8이 JavaScript를 실행하는 방법을 더 잘 이해하는 데 도움이 되기를 바랍니다. 하지만 자신만의 알고리즘을 최적화하는 데에도 집중하세요!