사람들에게 For 루프가 나쁘다고 말하지 마세요

할 말이 있었다. 때때로 "루프가 좋지 않습니다. 대신 필터, 매핑 및 축소를 사용해야 합니다."와 같은 게시물이 표시되는 것을 봅니다. 게시물을 볼 때마다 이가 갈립니다. 모든 것을 반복하려면 이러한 기능적 방법을 사용해야 합니다.

예, 이러한 기능적 방법에는 목적과 유효한 용도가 있습니다. 나는 당신이 그것들을 사용해서는 안 된다고 주장하는 것이 아니라 모든 것에 그것들을 사용하는 것에 반대하는 것입니다. 많은 경우에 성능 좋은 코드를 작성하려면 for 루프가 항상 더 빠른 옵션이 될 것입니다.
map , filter 및 reduce와 같은 메서드의 전체 목적은 전달되는 항목의 돌연변이를 방지하는 것입니다. FP(함수형 프로그래밍) 스타일에서 이러한 메서드에 배열을 전달하면 새 컬렉션이 반환되고 원본은 그대로 유지됩니다.
map의 경우(가장 남용되고 성능이 가장 낮은 것으로 보이므로) for 루프와 비교할 때 그 차이가 상당할 수 있습니다. 그 이유는 map이 새 복사본을 만들고 모든 반복에서 콜백을 실행하고 더 많은 메모리를 소비하기 때문입니다. for 루프는 반복하는 모든 작업에서 작동하므로 오버헤드가 거의 없습니다.

누군가가 비교 작업을 수행한 곳이 있습니다created a repository. 데이터의 큰 결과에 대한 결과는 놀랍습니다(이러한 방법의 작동 방식을 안다면 전혀 놀라운 일이 아닙니다).

내 웹 응용 프로그램에서 나는 예전보다 요즘 map , filter 및 reduce 더 많이 사용하는 경향이 있습니다. 그러나 for 루프는 이러한 방법이 할 수 없는 일을 할 수 있기 때문에 어떤 경우에는 for 루프가 더 나은 옵션이라는 점을 염두에 둡니다.

루프 끊기

이미 알고 있을 수도 있지만 for 루프는 break 키워드를 사용하여 중지할 수 있습니다. 특정 항목을 찾거나 특정 반복 횟수가 실행될 때까지 for 루프를 사용하여 배열을 반복하는 경우 루프에서 break를 실행하여 루프를 중지할 수 있습니다.

반대로 map , filter 및 reduce는 본질적으로 멈출 수 없습니다. 배열의 모든 항목을 검토할 때까지 반복합니다.

비동기 루프

for 루프는 async/await와 함께 쉽게 사용할 수 있습니다. 즉, 루프를 일시 중지하고 반복되는 다음 값으로 진행하기 전에 약속이 해결될 때까지 기다릴 수 있습니다.

함수형 메서드map, filter 및 reduce는 혼합에 async/await를 던지려고 할 때 난류입니다. 누산기를 기다리면 reduce 어느 정도 작동하게 할 수 있다고 생각하지만 옳지 않다고 느낍니다.

for 루프를 사용하면 쉽게 만들 수 있는데 왜 스스로를 힘들게 만들까요? 그리고 예, async/await는 모든 종류의 for 루프에서 작동합니다.

당신은 이것을하고 있습니까? 그만해요.

async function loadValues() {
    let myValues = await getValuesFromApi();

    myValues = myValues.map(value => {
        value.total = value.price * value.quantity;
        return value;
    });
}

매핑되는 바로 그 배열에 재할당되는 결과에 대해서만 개체 배열을 반복하는 데 사용되는 맵을 본 횟수는 셀 수 없을 정도로 많습니다. map의 요점은 많은 사람들이 map를 루프로 사용하고 결과를 새 변수 대신 원래 변수에 다시 할당한다는 점을 제외하고 배열의 새 복사본을 만드는 것입니다.

당신이 이것을하고 있다면 이미 그것을 중지하십시오. for 루프를 사용하세요. 이것이 바로 당신이 하고 있는 일이고 이 경우 map를 사용해도 아무런 이점이 없기 때문입니다.

결론

많은 경우에 앞서 언급한 기능적 방법을 기존의 for 루프에서 사용하면 성능 저하를 느끼지 못할 것입니다. 수만 또는 수십만 개의 데이터를 다루지 않는다면 100ms의 차이를 볼 수 없을 것입니다.

쓰기 편한 대로 작성하고 성능이 이상적이지 않은 경우 브라우저 개발자 도구와 상식을 사용하여 애플리케이션의 어느 부분을 최적화할 수 있는지 정확히 찾아낼 수 있습니다.

기억하십시오: 섣부른 최적화는 모든 악의 근원입니다