JS 최적화 원칙

不言원래의: 2018-04-26 14:43:531129검색

이 글은 js 최적화의 원칙을 여러분과 공유하기 위한 것입니다. 내용이 꽤 좋습니다. 관심 있는 친구들은 한 번 살펴보세요

우선, 다른 언어와 달리 JS의 효율성은 JS 엔진의 효율성에 크게 좌우됩니다. 엔진 구현의 장단점 외에도 엔진 자체는 일부 특수 코드 패턴에 대한 몇 가지 최적화 전략을 채택합니다. 예를 들어 FF, Opera 및 Safari의 JS 엔진은 문자열 연결 작업(+)을 특별히 최적화했습니다. 당연히, 최대 효율을 달성하기 위해서는 엔진의 기질을 이해하고 엔진의 취향에 부응하도록 노력해야 합니다. 따라서 서로 다른 엔진의 경우 최적화가 서로 상충될 가능성이 가장 높습니다.

그리고 크로스 브라우저 웹 프로그래밍을 한다면 가장 큰 문제는 IE6(JScript 5.6)입니다! hotfix가 없으면 JScript 엔진의 가비지 수집 버그로 인해 실제 응용 프로그램의 성능이 다른 브라우저와 동일하지 않게 됩니다. 따라서 이 상황에서 최적화하는 것은 실제로 JScript에 최적화하는 것입니다!

첫 번째 원칙은 IE6(패치되지 않은 JScript 5.6 이하)에만 최적화 입니다!

프로그램이 IE6에서 허용 가능한 성능으로 최적화된 경우 기본적으로 다른 브라우저에서의 성능에는 문제가 없습니다.

따라서 아래에서 설명하는 많은 문제는 다른 엔진에서 완전히 다를 수 있다는 점에 유의하세요. 예를 들어 루프의 문자열 연결은 일반적으로 Array.join을 사용해야 하는 것으로 간주되지만 문자열로 인해. SpiderMonkey와 같은 엔진의 "" +" 작업이 최적화되었으며 결과적으로 Array.join을 사용하는 것은 "+"를 직접 사용하는 것만큼 효율적이지 않습니다! 그러나 IE6을 고려한다면 다른 브라우저에서의 이러한 효율성 차이는 전혀 언급할 가치가 없습니다.

JS 최적화는 여전히 다른 언어의 최적화와 동일합니다. 예를 들어, 최적화를 시작하자마자 서두르지 마세요. 그건 의미가 없습니다. 최적화의 핵심은 여전히 가장 중요한 부분인 병목 현상에 집중하는 것입니다. 일반적으로 병목 현상은 대규모 루프에서 항상 나타납니다. 이는 루프 자체에 성능 문제가 있다는 의미는 아니지만 루프가 가능한 성능 문제를 빠르게 증폭시킬 수 있다는 의미입니다.

두 번째 원칙은 대규모 루프를 주요 최적화 개체로 삼는 것입니다.

다음 최적화 원칙은 대규모 루프에서만 의미가 있습니다. 이러한 최적화는 루프 본문 외부에서 수행하는 것이 기본적으로 의미가 없습니다.

현재 대부분의 JS 엔진은 해석되어 실행되며, 해석된 실행의 경우 모든 작업에서 함수 호출의 효율성이 낮습니다. 또한 지나치게 깊은 프로토타입 상속 체인이나 다중 레벨 참조도 효율성을 감소시킵니다. JScript에서 수준 10 참조의 오버헤드는 빈 함수 호출의 오버헤드의 약 1/2입니다. 두 가지 모두의 오버헤드는 간단한 연산(예: 4개의 산술 연산)보다 훨씬 큽니다.

세 번째 원칙은 너무 많은 참조 레벨과 불필요한 다중 메소드 호출을 피하는 것입니다.

어떤 경우에는 속성 액세스처럼 보이는 것이 실제로는 메서드 호출이라는 점에 유의하는 것이 중요합니다. 예를 들어 모든 DOM 속성은 실제로 메서드입니다. NodeList를 순회할 때 node.length에 대한 루프 조건의 액세스는 속성 읽기처럼 보이지만 실제로는 함수 호출과 동일합니다. 또한 IE DOM 구현에서는 매번 내부 순회를 통해 childNodes.length를 다시 계산해야 합니다. (맙소사, 이게 사실이에요! childNodes.length의 액세스 시간이 childNodes.length의 값에 비례한다는 것을 측정했기 때문입니다!) 이것은 매우 비쌉니다. 따라서 node.length를 미리 js 변수에 저장하면 순회 성능이 확실히 향상될 수 있습니다.

함수 호출이기도 하며 사용자 정의 함수의 효율성은 언어 내장 함수보다 훨씬 낮습니다. 왜냐하면 후자는 엔진의 기본 메서드에 대한 래퍼이고 엔진은 일반적으로 다음 언어로 작성되기 때문입니다. c, C++, 자바. 또한 동일한 함수의 경우 내장 언어 구성의 비용은 일반적으로 내장 함수 호출보다 더 효율적입니다. 왜냐하면 전자는 JS 코드의 구문 분석 단계에서 결정되고 최적화될 수 있기 때문입니다.

그래서 네 번째 원칙은 언어 자체의 구조와 내장 기능을 최대한 사용하는 것입니다.

다음은 고성능 String.format 방법의 예입니다. String.format의 전통적인 구현은 String.replace(regex, func)를 사용하는 것입니다. 패턴에 n개의 자리 표시자(반복되는 항목 포함)가 포함되어 있으면 사용자 정의 함수 func가 n번 호출됩니다. 이 고성능 구현에서 각 형식 호출은 Array.join만 수행한 다음 String.replace(regex, string) 작업을 수행합니다. 둘 다 사용자 정의 함수 호출 없이 엔진의 내장 메서드입니다. 2개의 내장 메소드 호출과 n개의 커스텀 메소드 호출, 이것이 바로 성능의 차이입니다.

기본 제공되는 기능이기도 하지만 여전히 성능에는 차이가 있습니다. 예를 들어, JScript에서 인수의 액세스 성능은 매우 좋지 않아 함수 호출을 거의 따라잡을 수 있습니다. 따라서 가변 매개변수를 사용하는 단순한 함수가 성능 병목 현상이 발생하는 경우 내부적으로 일부 변경을 하고 인수에 액세스하지 않고 매개변수에 대한 명시적인 판단을 통해 처리할 수 있습니다.

예:

Java 코드

function sum() {
var r = 0;
for (var i = 0; i
r += 인수[i]
}
return r;
}

이 합계는 일반적으로 작은 숫자로 호출되며 매개 변수가 적을 때 성능이 향상되기를 바랍니다. 다음으로 변경된 경우:

Java 코드

function sum() {
switch (args.length) {
케이스 1: return 인수[0];
] + 인수[1] [ 0] + 인수[1] + 인수[2
] + 인수[
]
var r = 0
논증 [i]; 실제로, 개선이 크지 않지만 다음으로 변경되는 경우 :
자바 코드
함수 sum(a, b, c, d, e, f, g) {
var r = a ? c ? d ? e + f : a + b + c + d + e : a + b + c + d : a + b + c : a + b : a : 0
if (g = == 정의되지 않음)
return

for

(var i =
6; i

= 인수[i]

}

많이 개선될 것입니다(최소 1배 더 빠름).

마지막은 실제 애플리케이션에서 가장 중요한 성능 장애물이 되는 다섯 번째 원칙, 즉 불필요한 객체 생성을 최소화하는 것입니다.

오브젝트를 만드는 것 자체에는 일정한 비용이 들지만, 이 비용은 사실 크지 않습니다. 가장 근본적인 문제는 JScript의 극도로 어리석은 가비지 수집 스케줄링 알고리즘이 개체 수가 증가함에 따라 심각한 성능 저하를 초래한다는 것입니다(Microsoft 직원에 따르면 복잡성은 O(n^2)입니다).

예를 들어 일반적인 문자열 연결 문제는 테스트 검증을 통해 단순히 문자열 개체를 여러 번 생성하는 것만으로는 성능 저하의 원인이 전혀 아닙니다. 가장 나쁜 부분은 객체 생성 중 불필요한 가비지 수집으로 인한 오버헤드입니다. Array.join 메서드는 중간 문자열 개체를 생성하지 않으므로 가비지 수집 오버헤드가 줄어듭니다.

따라서 대규모 객체 생성을 단일 명령문으로 변환할 수 있다면 성능이 크게 향상될 것입니다! 예를 들어 코드를 구성한 후 평가하는 방식으로 - 실제로 PIES 프로젝트는 이러한 아이디어를 기반으로 전문적인 대규모 객체 생성기를 구축하고 있습니다...

자, 이상이 JS 최적화의 5가지 원칙입니다. 제가 요약한 것입니다.

Reposted from -----hax의 기술 블로그 http://hax.iteye.com/blog/126859

JS 최적화 원칙

관련 기사