JavaScript_javascript 기술에서 for 루프의 효율성 문제 및 관련 최적화에 대한 심층 탐구

Underscore.js 라이브러리

하루(주)에 몇 개의 루프를 작성하셨나요?

var i;
for(i = 0; i < someArray.length; i++) {
 var someThing = someArray[i];
 doSomeWorkOn(someThing);
}

물론 무해하지만 보기 흉하고 이상하며 실제로 불평할 정도는 아닙니다. 하지만 이런 글쓰기 방식은 너무 진부하다.

var i,
 j;
for(i = 0; i < someArray.length; i++) {
 var someThing = someArray[i];
 for(j = 0; j < someThing.stuff.length; j++) {
   doSomeWorkOn(someThing.stuff[j]);
 }
}

잘못된 코드를 확장하고 있으며 ifs를 여러 번 던지기 전에 이미 미친 상태입니다.
나는 2년 동안 루프를 작성하지 않았습니다.
"무슨 소리야?"
사실이에요, 나쁜 농담이에요. 루프를 작성하지 않고 코드가 이해하기 더 쉽기 때문에 실제로는 없습니다(그래요, 몇 개 작성했습니다).
어떻게?

_.each(someArray, function(someThing) {
 doSomeWorkOn(someThing);
})

또는 더 나은 방법:

_.each(someArray, doSomeWorkOn);

이것이 underscorejs가 하는 일입니다. 깔끔하고 단순하며 읽기 쉽고 짧으며 중간 변수도 없고 세미콜론도 없고 단순하고 매우 우아합니다.
다음은 몇 가지 예입니다.

var i,
 result = [];
for(i = 0; i < someArray.length; i++) {
 var someThing = someArray[i];
 // 打到这，我已经手疼了
 if(someThing.isAwesome === true) {
   result.push(someArray[i]);
 }
}

다시 말하지만, 루프를 사용하여 시간을 낭비하는 일반적인 사용 사례입니다. 비록 이러한 사이트들이 금연과 채식주의를 장려하고 있음에도 불구하고, 저는 이러한 코드들을 볼 때 분노를 느낍니다. 간단한 작성 방법을 살펴보세요.

var result = _.filter(someArray, function(someThing) {
 return someThing.isAwesome === true;
})

밑줄에 있는 필터 이름처럼 코드 3줄만으로 새로운 배열을 만들 수 있습니다.
아니면 이 배열을 다른 형식으로 변환하시겠습니까?

var result = _.map(someArray, function(someThing) {
 return trasformTheThing(someThing);
})

위의 세 가지 예는 일상생활에서는 충분하지만 밑줄을 테이블 위에 올려놓기에는 이 기능만으로는 충분하지 않습니다.

var grandTotal = 0,
 somePercentage = 1.07,
 severalNumbers = [33, 54, 42],
 i; // don't forget to hoist those indices;
for(i = 0; i < severalNumbers.length; i++) {
 var aNumber = severalNumbers[i];
 grandTotal += aNumber * somePercentage;
}

밑줄 버전

var somePercentage = 1.07,
 severalNumbers = [33, 54, 42],
 grandTotal;
grandTotal = _.reduce(severalNumbers, function(runningTotal, aNumber) {
 return runningTotal + (aNumber * somePercentage);
}, 0)

처음에는 조금 이상해 보일 수도 있는데, Reduce에 대한 문서를 확인하고 그 존재를 알게 되었습니다. 나는 루프 사용을 거부하기 때문에 이것이 나의 첫 번째 선택입니다. 위의 내용은 단지 소개에 불과합니다. underscorejs 라이브러리에도 멋진 기능이 많이 있습니다.

30일 무사용주기 챌린지.

앞으로 30일 동안 루프를 사용하지 마세요. 지저분하고 거친 것들이 많이 보이면 각각 또는 맵으로 교체하세요. 좀 더 줄여서 사용하세요.

Underscore는 함수형 프로그래밍의 관문이라는 점에 유의해야 합니다. 보이는, 보이지 않는 방식. 좋은 방법입니다.

OurJS 참고* 최신 브라우저는 현재 각각, 필터, 맵 및 축소 메소드를 지원하지만 밑줄 라이브러리는 이전 버전의 IE와 호환될 수 있습니다. 다음은 ES5 기본 메소드를 사용하여 작성된 예입니다.

[3,4,5,3,3].forEach(function(obj){
  console.log(obj);
});

[1,2,3,4,5].filter(function(obj){
  return obj < 3
});

[9,8,5,2,3,4,5].map(function(obj){
  return obj + 2;
});

[1,2,3,4,5].reduce(function(pre, cur, idx, arr) {
  console.log(idx);  //4 个循环: 2-5
  return pre + cur;
});  //15

//sort方法同样很有用
[9,8,5,2,3,4,5].sort(function(obj1, obj2){
  return obj1 - obj2;
});

for in 및 for 루프

누군가는 for in의 효율성이 for 루프의 효율성보다 훨씬 낮다고 지적했습니다. 이제 대규모 배열을 처리할 때 다양한 브라우저에서 for in, for 루프 및 forEach를 사용하는 효율성을 테스트해 보겠습니다.

현재 대부분의 오픈 소스 소프트웨어는 for 루프에 배열 길이를 캐시합니다. 왜냐하면 일부 브라우저 Array.length는 매번 배열 길이를 다시 계산하므로 일반적으로 임시 변수를 사용하여 배열 길이를 저장하기 때문입니다. 예를 들어

for (var idx = 0, len = testArray.length; idx < len; idx++) {
 //do sth.
}

캐싱과 비캐싱 간의 성능 차이도 테스트해 보겠습니다.

또한 각 테스트 루프에 합산 연산을 추가하여 빈 루프가 아님을 보여줍니다.

for (var idx = 0, len = testArray.length; idx < len; idx++) {
 //do sth.
}

캐싱과 비캐싱 간의 성능 차이도 테스트해 보겠습니다.

또한 각 테스트 루프에 합산 연산을 추가하여 빈 루프가 아님을 보여줍니다.

테스트 코드는 다음과 같습니다. 실행을 눌러 확인하세요
HTML 코드

<h4 id="browser"></h4>
<table id="results" class="table"></table>

자바스크립트 코드

function () {

 //准备测试数据, 有200万条数据的大数组
 var testArray = []
  , testObject = {}
  , idx
  , len = 2000000
  , tmp = 0
  , $results = $("#results")
  , $browser = $("#browser")
  ;

 $browser.html(navigator.userAgent);
 $results.html('');

 for (var i = 0; i < len; i++) {
  var number = Math.random(); //若希望加快运算速度可使用取整：Math.random() * 10 | 0
  testArray.push(number);
  testObject[i] = number;
 }

 $results.append('<tr><th>测试代码</th><th>计算结果</th><th>所需时间,毫秒</th></tr>');

 //测试函数
 var test = function(testFunc) {
  var startTime
   , endTime
   , result
   ;

  startTime = new Date();
  tmp = 0;
  testFunc();
  endTime  = new Date();

  //计算测试用例(Test Case)运行所需要的时间
  result = endTime - startTime;
  $results.append('<tr><td><pre class="brush:php;toolbar:false">{0}

{1}{2}'.format(testFunc.toString(), tmp | 0, result)); }; test(function() { //测试for in 的效率 for (idx in testArray) { tmp += testArray[idx]; //经测试，idx是string类型，可能是慢的原因之一 } }); test(function() { //测试for loop循环的效率 for (idx = 0, len = testArray.length; idx < len; idx++) { tmp += testArray[idx]; } }); test(function() { //测试forEach的效率 testArray.forEach(function(data) { tmp += data; }); }); test(function() { //测试不缓存Array.length时效率 for (idx = 0; idx < testArray.length; idx++) { tmp += testArray[idx]; } }); test(function() { //测试使用{} (Object) 存健值对时，使用for in的效率如何 for (idx in testObject) { tmp += testObject[idx]; } }); test(function() { //测试从{} Object查值时的效率如何（这里的健key值事先己知） for (idx = 0, len = testArray.length; idx < len; idx++) { tmp += testObject[idx]; } }); }

[잠시만 기다려주세요] 달려가세요
테스트 결과
테스트 결과는 계산에 따라 달라질 수 있습니다. 내 컴퓨터에서 실행되는 Firefox, Chrome, IE의 테스트 결과를 요약한 것입니다.

다음은 몇 가지 관찰된 결론입니다

• For in은 for 루프보다 훨씬 느리며 Chrome에서는 최소 20배 느립니다
• FF는 forEach(ES5)에 최적화되어 있으며 for 루프보다 성능은 좋지만 Chrome/IEn 성능은 좋지 않습니다
• FF/Chrome 캐싱 Array.length는 직접 사용하는 것보다 약간 느립니다. 최신 버전의 IE를 제외하면 성능 향상이 미미합니다(이건 정말 예상치 못한 일입니다)
• 어떤 경우에는 FF의 JS 엔진 성능이 V8보다 나은 것 같습니다