많은 개발자가 작업을 수행하는 다양한 방법을 더 많이 배울 때 성능 최적화에 관심이 있다고 생각합니다. 내부에서는 "어떤 길이 가장 좋은지 묻는 목소리도 있다. Douglas Crockford의 2008년 JavaScript: The Good Parts처럼 "최고"에 대한 지표는 다양하지만 성능은 직접 테스트할 수 있기 때문에 접근 가능합니다.
그러나 성능을 테스트하고 입증하는 일이 항상 쉬운 것은 아닙니다.
2000년대 초반에는 Internet Explorer가 최초의 브라우저 전쟁에서 승리했습니다. IE는 한동안 Mac의 기본 브라우저이기도 했습니다. 한때 지배적이었던 Netscape는 AOL에 매각되었고 결국 폐쇄되었습니다. Mozilla는 새로운 독립형 브라우저 Phoenix Firebird Firefox를 위해 수년간 베타 버전을 선보였습니다.
2003년 Opera 7은 새롭고 더 빠른 렌더링 엔진인 Presto와 함께 출시되었습니다. 또한 Apple은 잘 알려지지 않은 Konqueror KHTML 엔진을 기반으로 구축된 Mac용 성능 중심 브라우저인 Safari를 출시했습니다. Firefox는 2004년에 공식적으로 출시되었습니다. Microsoft는 2006년에 IE 7을 출시했고 Opera 9는 더 빠른 JavaScript 엔진을 출시했습니다. 2007년에는 Windows와 새로운 iPhone 모두에 Safari가 도입되었습니다. 2008년에는 Google Chrome과 Android 브라우저가 등장했습니다.
더 많은 브라우저와 더 많은 플랫폼이 등장하면서 이 기간의 핵심은 성능이었습니다. 새로운 브라우저 버전은 정기적으로 가장 빠른 새 브라우저라고 발표되었습니다. Apple의 SunSpider 및 Mozilla의 Kraken과 같은 벤치마크는 릴리스에서 자주 인용되었으며 Google은 자체 Octane 테스트 제품군을 유지했습니다. 2010년에 Chrome 팀은 브라우저의 성능을 입증하기 위해 일련의 '속도 테스트' 실험도 수행했습니다.
미시 성능 테스트는 2010년대에 많은 주목을 받았습니다. 웹은 제한된 페이지 상호 작용에서 완전한 클라이언트 측 단일 페이지 응용 프로그램으로 전환되고 있었습니다. Nicholas Zakas의 2010 High Performance JavaScript와 같은 책에서는 사소해 보이는 디자인 선택과 코딩 방식이 어떻게 성능에 의미 있는 영향을 미칠 수 있는지를 보여주었습니다.
머지않아 JavaScript 엔진 대회에서는 고성능 JavaScript의 주요 성능 문제 중 일부를 다루게 되었고, 엔진의 급격한 변화로 인해 현재 무엇이 최선인지 파악하기가 어려워졌습니다. 새로운 브라우저 버전과 모바일 장치가 등장하면서 마이크로 성능 테스트가 뜨거운 주제가 되었습니다. 2015년에는 현재는 폐쇄된 성능 테스트 사이트인 jsperf.com이 스팸으로 인해 성능 문제를 겪을 정도로 인기가 높았습니다.
JavaScript 엔진이 발전하면서 테스트를 작성하기는 쉬워졌지만 테스트가 공정하거나 심지어 유효한지 확인하기가 어렵습니다. 테스트에서 많은 메모리를 소비한 경우 이후 테스트에서 가비지 수집으로 인해 지연이 발생할 수 있습니다. 모든 테스트에서 설정 시간이 계산되거나 제외되었습니까? 테스트에서도 동일한 결과가 나왔나요? 테스트의 맥락이 중요했나요? !~arr.indexOf(val) 대 arr.indexOf(val) === -1을 테스트한 경우 표현식을 실행하거나 if 조건에서 사용하는 경우 차이가 있습니까?
스크립트 인터프리터가 다양한 컴파일러로 교체되면서 우리는 컴파일된 코드의 장점과 부작용, 즉 최적화를 확인하기 시작했습니다. 예를 들어 부작용이 없는 루프에서 실행되는 코드는 완전히 최적화될 수 있습니다.
// Testing the speed of different comparison operators
for (let i = 0; i < 10000; i += 1) {
a === 10;
}
출력이나 부작용 없이 10000번의 작업을 수행하기 때문에 최적화 시 완전히 폐기될 수 있습니다. 하지만 보장된 것은 아닙니다.
또한 미세 최적화는 출시마다 크게 변경될 수 있습니다. 불행하게도 jsperf.com이 폐쇄됨에 따라 다양한 브라우저 버전에 대한 수백만 건의 과거 테스트 비교가 손실되었지만 이는 시간이 지남에 따라 오늘날에도 여전히 볼 수 있습니다.
미세 최적화 성능 테스트에는 많은 주의 사항이 따른다는 점을 명심하는 것이 중요합니다.
성능 개선이 정체되기 시작하면서 테스트 결과가 반등하는 것을 확인했습니다. 그 중 일부는 엔진 개선이었지만 공통 패턴에 맞게 코드를 최적화하는 엔진도 보았습니다. 더 나은 코딩 솔루션이 존재하더라도 모든 사이트가 변경될 것이라고 기대하는 것보다 일반적인 코드 패턴을 최적화하는 것이 사용자에게 실질적인 이점이 있었습니다.
2018년에는 변화하는 브라우저 성능보다 더 나쁜 것은 Spectre 및 Meltdown과 같은 예측 실행 공격을 완화하기 위해 타이머의 정확성과 정밀도가 변경된 것입니다. 관심이 있으신 분들을 위해 이러한 타이밍 문제에 대해 별도의 기사를 썼습니다.
문제를 복잡하게 만들기 위해 최신 브라우저에 대해 테스트하고 최적화합니까, 아니면 프로젝트에서 지원되는 수준이 가장 낮은 브라우저에 대해 테스트하고 최적화합니까? 마찬가지로, 스마트폰이 인기를 얻으면서 처리 능력이 현저히 낮은 휴대용 장치가 중요한 고려 사항이 되었습니다. 최상의 결과 또는 가장 영향력 있는 결과를 위해 어디에 시간을 할당해야 하는지 아는 것이 더욱 어려워졌습니다.
성급한 최적화는 만악의 근원입니다.
-- 도널드 크누스
자주 인용되는 내용입니다. 사람들은 이를 사용하여 최적화에 대해 생각할 때마다 상상의 또는 미미한 이득을 위해 시간을 낭비하고 코드를 악화시키는 것이라고 제안합니다. 이는 아마도 많은 경우에 해당될 것입니다. 하지만 인용문에는 더 많은 내용이 있습니다.
약 97%의 경우 작은 효율성은 잊어야 합니다. 성급한 최적화는 모든 악의 근원입니다. 하지만 우리는 그 중요한 3%의 기회를 놓쳐서는 안 됩니다.
더 완전한 인용문은 중요한 맥락을 추가합니다. 우리가 그렇게 한다면 작은 효율성에 많은 시간을 할애할 수 있습니다. 이는 많은 가치를 제공하지 못한 채 프로젝트 목표에 비해 시간이 걸리는 경우가 많습니다.
저는 개인적으로 이러한 최적화에 많은 시간을 투자했는데 지금으로서는 전혀 낭비가 아닌 것 같았습니다. 그러나 돌이켜보면 그 작업이 얼마나 가치가 있었는지는 분명하지 않습니다. 그 당시 제가 작성한 코드 중 일부는 실행 시간을 밀리초 단위로 줄였을 것이라고 확신하지만, 절약된 시간이 중요.
하다고는 말할 수 없습니다.Google은 2017년 Octane 테스트 제품군 종료로 인한 수익 감소에 대해서도 이야기합니다. 해당 작업을 전담하는 팀이 경험한 성능 최적화의 한계와 문제에 대한 훌륭한 통찰력을 얻으려면 이 게시물을 읽어 보시기를 강력히 권장합니다.
그럼 "중요한 3%"에 어떻게 집중할 수 있을까요?
코드가 언제 어떻게 사용되는지 이해하면 어디에 집중해야 할지 더 나은 결정을 내리는 데 도움이 됩니다.
얼마 지나지 않아 성능이 향상되고 새로운 브라우저의 변형으로 인해 이러한 종류의 마이크로 테스트에서 플레임 차트와 같은 더 광범위한 도구가 사용되기 시작했습니다.
30분 시간이 있다면 V8 엔진에 관한 2015 Chrome DevSummit 프레젠테이션을 추천합니다. 브라우저가 계속 변경되고 이러한 세부 사항을 따라가는 것이 어려울 수 있다는 문제가 바로 이러한 문제에 대해 설명합니다.
실행 중인 애플리케이션의 성능 모니터링 및 분석을 사용하면 코드의 어떤 부분이 느리게 실행되거나 자주 실행되는지 빠르게 식별하는 데 도움이 됩니다. 이를 통해 최적화를 살펴볼 수 있는 좋은 위치에 있습니다.
성능 모니터링 도구와 라이브러리를 사용하면 코드가 어떻게 실행되는지, 어떤 부분에 작업이 필요한지 확인할 수 있습니다. 또한 다양한 영역에서 다양한 플랫폼이나 브라우저에서 작업이 필요한지 확인할 수 있는 기회도 제공합니다. 메모리와 eMMC 저장 공간이 제한된 Chromebook에서는 localStorage가 훨씬 느릴 수도 있습니다. 느리거나 불안정한 셀룰러 서비스를 방지하기 위해 더 많은 정보를 캐시해야 할 수도 있습니다. 무엇이 잘못되었는지 추측할 수 있지만 측정하는 것이 훨씬 더 나은 해결책입니다.
고객 기반이 충분히 크다면 실제 고객 경험이 어떤지 알 수 있는 실제 사용자 모니터링(RUM) 도구를 사용하여 이점을 얻을 수 있습니다. 이는 이 기사의 범위를 벗어나지만 고객 경험의 범위를 이해하고 실제 성능 및 오류 처리에 집중하기 위해 여러 회사에서 이를 사용했습니다.
'이 문제를 어떻게 개선할 수 있나요?'에 대해 알아보는 것은 쉽지만 이것이 항상 최선의 대답은 아닙니다. 한발 물러서서 "이것이 이 문제에 대한 올바른 해결책인가?"라고 질문하면 많은 시간을 절약할 수 있습니다.
DOM에 매우 큰 요소 목록을 로드하는 데 문제가 있나요? 페이지에 보이는 요소만 로드되는 가상화된 목록이 성능 문제를 해결할 수도 있습니다.
클라이언트에서 복잡한 작업을 많이 수행하시나요? 이 중 일부 또는 전부를 서버에서 계산하는 것이 더 빠를까요? 일부 작업을 캐시할 수 있나요?
더 큰 단계로 되돌아가기: 이것이 이 작업에 적합한 사용자 인터페이스입니까? 20개 항목을 예상하도록 드롭다운을 디자인했는데 현재 3,000개 항목이 있는 경우 선택을 위해 다른 구성 요소나 경험이 필요할 수 있습니다.
모든 공연 작업에는 '충분하다'라는 두 번째 질문이 있습니다. Stand-up Maths의 Matt Parker가 자신이 작성한 일부 코드와 그의 커뮤니티가 코드를 주 런타임에서 밀리초로 개선한 방법에 대해 설명하는 훌륭한 동영상이 있습니다. 이러한 최적화가 가능하다는 것이 믿기지 않지만, 거의 모든 프로젝트에 "충분히 좋음"에 도달하는 지점도 있습니다.
Pour un programme exécuté une seule fois, des semaines peuvent être acceptables, des heures seraient mieux, mais le temps que vous y consacrez devient rapidement une considération importante.
Vous pourriez y penser comme des tolérances en ingénierie. Nous avons un objectif et nous avons une gamme d’acceptation. Nous pouvons viser la perfection tout en comprenant que le succès et la perfection ne sont pas la même chose.
Les objectifs sont un élément essentiel de l'optimisation. Si seulement vous savez que la situation actuelle est mauvaise, « l’améliorer » est un objectif illimité. Sans objectif pour votre parcours d'optimisation, vous pouvez perdre du temps à essayer de trouver plus de performances ou plus d'optimisation alors que vous pourriez travailler sur quelque chose de plus important.
Je n'ai pas de bonne métrique pour cela car l'optimisation des performances peut varier énormément, mais essayez de ne pas vous perdre dans les mauvaises herbes. Il s'agit vraiment de gestion de projet et de planification plus que de solutions de codage, mais la contribution des développeurs est importante lors de la définition des objectifs d'optimisation. Comme suggéré dans la section Alternatives, le correctif n'est peut-être pas « rendre cela plus rapide ».
Dans le cas de Matt Parker, il avait besoin de la réponse éventuellement, et n'avait pas besoin d'utiliser l'appareil pour autre chose. Dans notre monde, nous mesurons souvent la performance des visiteurs et son impact financier probable par rapport au temps du développeur/de l'équipe et votre coût d'opportunité, donc la mesure n'est pas aussi simple.
Imaginons que nous savons que réduire notre temps d'ajout au panier de 50 % augmenterait nos revenus de 10 %, mais il faudra deux mois pour terminer ce travail. Y a-t-il quelque chose qui pourrait avoir un impact financier plus important que deux mois de travail d’optimisation ? Pouvez-vous obtenir certains avantages dans un laps de temps plus court ? Encore une fois, il s'agit de gestion de projet plutôt que de code.
Lorsque vous avez besoin d'optimiser le code, c'est également le bon moment pour voir si vous pouvez séparer ce code des autres parties de votre projet. Si vous savez que vous devez écrire des optimisations complexes qui rendront le code difficile à suivre, l'extraire vers un utilitaire ou une bibliothèque peut faciliter sa réutilisation et vous permettre de mettre à jour cette optimisation en un seul endroit si elle doit changer au fil du temps.
La performance est un sujet compliqué avec beaucoup de rebondissements. Si vous ne faites pas attention, vous pouvez investir beaucoup d’énergie pour très peu de gains pratiques. La curiosité peut être un bon professeur, mais elle ne donne pas toujours des résultats. Il y a un avantage à jouer avec les performances du code, mais aussi un moment pour analyser les sources réelles de lenteur de votre projet et utiliser les outils disponibles pour aider à les résoudre.
위 내용은 JavaScript 마이크로 성능 테스트, 역사 및 제한 사항의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
