실패한 jQuery 최적화 try_jquery 요약

(이것은 jQuery의 성능이 우수하다는 것을 의미하지는 않습니다. 오히려 상대적으로 폐쇄적인 라이브러리라 외부에서 최적화할 수 없다고 말할 수 있을 뿐입니다.) 이 문서에는 실패한 최적화 경험이 기록되어 있습니다.
최적화 아이디어
이번 최적화 아이디어는 데이터베이스에서 나왔습니다. 데이터베이스를 최적화할 때 우리는 종종 "한 트랜잭션에서 많은 수의 작업을 함께 커밋하면 효율성이 효과적으로 향상될 수 있다"고 말합니다. 데이터베이스에 대해 잘 모르기 때문에 이유는 모르겠지만, "트랜잭션"이라는 개념이 나에게 방향을 제시해주었다(틀렸지만...).
그래서 저는 jQuery에 "트랜잭션"이라는 개념을 도입하려고 시도했고, 트랜잭션을 "열기"와 "제출"하여 외부에서 jQuery를 일부 최적화했습니다. 가장 중요한 것은 각 함수의 루프 수를 줄이는 것입니다. .
우리 모두 알고 있듯이 jQuery의 DOM 작업은 모두 가져오기 및 설정을 먼저 기반으로 합니다. DOM 속성/스타일을 설정하는 데 사용되는 작업은 선택한 요소의 거의 모든 순회입니다. , 반복 코드는 다음과 같습니다.

코드 복사 코드는 다음과 같습니다.

/ / 하나의 속성 설정
if ( value !== undefine ) {
// 선택적으로 exec가 true인 경우 함수 값이 실행됩니다.
exec = !pass && exec && jQuery.isFunction(value) ;
for ( var i = 0; i fn(
elems[i],
key,
exec ? value.call(elems[i] , i, fn(elems[i], key)) : value,
pass
)
}
return elems;

, jQuery.fn은 다음과 같습니다.

코드 복사 코드는 다음과 같습니다.

jQuery.fn.css = function( 이름, 값 ) {
// '정의되지 않음' 설정은 아무 작업도 하지 않습니다.
if ( 인수.길이 === 2 && 값 === 정의되지 않음 ) {
return this;
}
return jQuery.access( this, name, value, true, function( elem, name, value ) {
return value !== 정의되지 않음 ?
jQuery. style( elem, name, value ) :
jQuery.css( elem, name );
})


따라서 다음 코드는 5000개의 div 요소를 선택한 다음 10000개의 노드를 반복하려면:

jQuery('div').css('height', 300).css('width', 200)
그리고 내 생각에는 "트랜잭션"은 데이터베이스 작업과 마찬가지로 모든 작업을 저장하고 "트랜잭션 제출" 시 균일하게 수행함으로써 10,000개의 노드 액세스를 5,000으로 줄일 수 있으며 이는 "1x" 성능 향상에 해당합니다.

간단한 구현
"트랜잭션" jQuery 작업에서는 2가지 함수가 제공됩니다. 시작: "트랜잭션"을 열고 트랜잭션 개체를 반환합니다. 이 객체에는 jQuery의 모든 기능이 있지만 함수를 호출하면 즉시 적용되지 않고 "트랜잭션 제출" 후에만 적용됩니다.
커밋: 이전에 호출한 모든 함수가 적용되고 원래 jQuery 개체를 반환하도록 "트랜잭션"을 제출합니다.
구현하는 것도 매우 편리합니다.
"트랜잭션 개체"를 만들고 jQuery.fn의 모든 기능을 개체에 복사합니다.
함수를 호출할 때 미리 준비된 "대기열"에 호출된 함수 이름과 관련 매개변수를 추가합니다.
트랜잭션이 커밋되면 선택한 요소에 대해 순회가 수행되고 "큐"의 모든 기능이 순회의 각 노드에 적용됩니다.
간단히 코드는 다음과 같습니다.

코드를 복사하세요 코드는 다음과 같습니다.

var Slice = Array .prototype.slice;

jQuery.fn.begin = function() {
var Proxy = {
_core: c,
_queue: []
},
key,
func;//jQuery.fn에 함수 복사
for(jQuery.fn의 키) {
func = jQuery.fn[key]
if (typeof func == ' function') {
//키가 항상 마지막 루프 값이라는 for 루프 때문에 여기에 문제가 있습니다
//따라서 유효성을 보장하기 위해 클로저를 사용해야 합니다 키의 (LIFT 효과)
(function( key) {
proxy[key] = function() {
//큐에 함수 호출 넣기
this._queue.push([ key, Slice.call(arguments, 0)]);
return this;
})(key)
}
}//커밋 함수 방지
proxy.commit = jQuery.fn.commit;
return Proxy;
}
jQuery.fn.commit = function() {
var core = this._core ,
queue = this._queue;
// 각 루프는 하나만
core.each(function() {
var i = 0,
item,
jq = jQuery( this);
//모든 함수 호출
for (; item = queue[i]; i ) {
jq[item[0]].apply(jq, item[1]); >}
});
return this.c


테스트 환경
테스트에서는 다음 조건을 사용합니다.
컨테이너(

)에 배치된 5000개의 div.
$('#container>div')를 사용하여 5000개의 div를 선택하세요.
각 div는 임의의 배경색(randomColor 함수)과 800px 미만의 임의 너비(randomWidth 함수)를 설정해야 합니다.
테스트에 참여하는 데는 3가지 호출 방법이 있습니다.
일반 사용법:

코드 복사 코드는 다음과 같습니다.

$('#container>div')
.css('Background-color', randomColor)
.css('width', RandomWidth);

단일 루프 방법:

코드 복사 코드 다음과 같습니다:

$('#container>div').each(function() {
$(this).css('Background-color', randomColor).css( 'width', randomWidth) ;
});

비즈니스 방법:

코드 복사 코드는 다음과 같습니다.

$('#container>div')
.begin()
.css('Background-color', randomColor)
.css(' width', randomWidth)
.commit();

객체 할당 방법:

코드 복사 코드는 다음과 같습니다.

$('#container>div').css({
'배경 -color': randomColor,
'width' : randomWidth
});

Chrome 8 시리즈를 테스트 브라우저로 선택합니다(IE로 테스트할 때 멈춥니다).
안타까운 결과
원래 예측 결과는 싱글 루프 방식보다 트랜잭션 방식이 느리지만, 동시에 일반 사용 방식보다 효율성이 훨씬 높다는 것이었습니다. 루프 방식을 사용하는 경우 일반 방식보다 속도가 빨라야 하며, 객체 할당 방식은 실제로 jQuery에서 내부적으로 지원하는 단일 루프 방식이므로 가장 효율적입니다.
안타깝게도 결과는 다음과 같습니다.
일반 사용 방식, 단일 루프 방식, 트랜잭션 방식, 객체 할당 방식
18435ms 18233ms 18918ms 17748ms
결과에서 트랜잭션 방식이 가장 느려졌습니다. 방법. 동시에 단일 루프와 일반 사용 사이에는 뚜렷한 이점이 없으며 jQuery 내부적으로 구현된 객체 할당 방법에 의존하더라도 큰 차이가 열리지 않습니다.
5000개 요소의 연산은 이미 매우 큰 루프이기 때문에 이러한 거대한 루프는 성능 격차를 넓힐 수 없습니다. 가장 일반적으로 사용되는 약 10개 요소의 연산은 뚜렷한 장점을 가질 가능성이 훨씬 적으며 단점을 확장할 수도 있습니다. .
이유는 단일 루프 방식 자체로는 뚜렷한 성능 향상이 없기 때문에 단일 루프에 의존하며 당연히 단일 루프를 기반으로 하는 외부 구축 방식이기도 하기 때문입니다. 트랜잭션 객체 생성, 함수 큐 저장, 함수 큐 탐색 등과 같은 추가 오버헤드가 필요합니다. 정상적인 사용으로 인해 결과가 패배하는 것이 합리적입니다.
현 시점에서는 '거래'를 모방하는 최적화 방식이 실패했다고 할 수 있습니다. 그러나 이 결과는 더 자세히 분석될 수 있습니다.
성능은 어디인가?
우선 코드의 사용법을 분석하고 테스트에서 가장 빠른 객체 할당 방법과 일반적인 사용법을 비교해 보면 차이가 난다고 할 수 있다. 둘 사이는 루프에만 있습니다. 요소 수의 차이(여기서 jQuery의 내부 문제는 제쳐두겠습니다. 실제로 jQuery.access의 잘못된 구현이 객체 할당 방법을 방해하지만 다행히 심각하지는 않습니다.) ), 일반적인 사용량은 10,000개 요소입니다. 개체 할당 방법은 5000개 요소입니다. 따라서 18435 - 17748 = 687ms는 5000개의 요소를 반복하는데 걸리는 시간이라고 간단히 생각할 수 있으며, 이는 전체 실행 프로세스의 약 3.5%를 차지합니다. 실제로는 전체 실행 프로세스의 백본이 아닙니다. 실제로 최적화가 필요하지 않습니다.

그럼 나머지 96.5%의 비용은 어디로 가나요? Doglas가 "사실 Javascript는 느린 것이 아닙니다. 느린 것은 DOM 작업입니다."라고 말한 것을 기억하십시오. 실제로 함수 호출 등 기본적인 소비를 제외한 나머지 96.5%의 오버헤드 중 DOM 요소의 스타일이 변경된 후 다시 렌더링하는 데 최소 95%의 시간이 소요됩니다.

이 사실을 발견한 후 우리는 실제로 더 정확한 최적화 방향을 갖게 되었습니다. 이는 프런트 엔드 성능의 기본 원칙 중 하나이기도 합니다. 많은 수의 하위 요소를 수정할 때 먼저 루트 상위 DOM 노드를 이동합니다. DOM 트리 밖으로. 따라서 다음 코드를 사용하여 다시 테스트하면

코드 복사 코드는 다음과 같습니다.

//$('#container')를 재사용하지 않는 것은 이미 나쁜 일입니다.
$('#container').detach().find('div')
.css('배경 - color', randomColor)
.css('width', randomWidth);
$('#container').appendTo(document.body);

테스트 결과는 항상 유지됩니다. 약 900ms에서는 이전 데이터보다 전혀 높은 수준이 아니며 실제 최적화는 성공적입니다.

교훈 및 요약
확실히 성능 병목 지점을 찾아 최적화하세요. 맹목적인 추측은 잘못된 극단적인 경로로 이어질 뿐입니다.
데이터가 말한다, 누구도 데이터 앞에서 말하면 안 된다!
'트랜잭션'의 방향이 틀렸다고는 생각하지 않습니다. jQuery가 '트랜잭션' 개념을 기본적으로 지원할 수 있다면 다른 최적화 지점이 있을까요? 예를 들어 트랜잭션은 DOM 트리에서 상위 요소를 자동으로 제거합니다.