실패한 jQuery 최적화 try_jquery 요약

/ / 하나의 속성 설정
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.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.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가지 호출 방법이 있습니다.
일반 사용법:

단일 루프 방법:

비즈니스 방법:

객체 할당 방법:

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 트리 밖으로. 따라서 다음 코드를 사용하여 다시 테스트하면

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

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