자바스크립트에서는 전역 변수 대신 로컬 변수를 최대한 많이 사용해야 합니다. 이 문장은 다들 아시겠지만, 누가 먼저 말했을까요? 왜 이런 일을 하는가? 이에 대한 근거가 있나요? 이렇게 하지 않으면 성능에 얼마나 많은 손실이 발생합니까? 이 글에서는 이러한 질문에 대한 답을 살펴보고 변수의 읽기 및 쓰기 성능과 관련된 요소가 무엇인지 근본적으로 이해하겠습니다.
【원본】JavaScript 변수 성능
【저자】니콜라스 C. 자카스
[번역] 자바스크립트에서는 왜 가능하면 지역 변수를 사용해야 하나요?
[번역자] 밍다
다음은 원문을 번역한 것입니다.
JavaScript 성능을 향상시키는 방법에 대해 가장 일반적으로 듣는 제안은 전역 변수 대신 지역 변수를 사용하라는 것입니다. 이는 웹 개발 분야에서 9년 동안 일하면서 한 번도 의문을 제기한 적이 없는 조언이며 JavaScript의 범위 지정 및 식별자 확인(식별자 확인) 방법 처리를 기반으로 합니다.
우선, JavaScript에서는 함수가 객체로 구현된다는 점을 분명히 해야 합니다. 함수를 생성하는 과정은 실제로 객체를 생성하는 과정입니다. 각 함수 개체에는 함수가 생성될 때의 범위 정보가 포함된 [[Scope]]라는 내부 속성이 있습니다. 실제로 [[Scope]] 속성은 객체(가변 객체)의 목록에 해당하며, 목록에 있는 객체는 함수 내에서 접근할 수 있습니다. 예를 들어, 전역 함수 A를 생성하면 A의 [[Scope]] 내부 속성에는 하나의 전역 객체(전역 객체)만 포함되고, A에서 새 함수 B를 생성하면 B의 [[Scope] ] 속성에는 다음이 포함됩니다. 두 개체, 함수 A의 활성화 개체 개체가 앞에 있고 전역 개체(Global Object)가 뒤에 있습니다.
함수가 실행되면 실행 가능한 객체(Execution Object)가 자동으로 생성되어 스코프 체인(Scope Chain)에 바인딩됩니다. 범위 체인은 식별자 확인을 위해 다음 두 단계를 통해 설정됩니다.
1. 먼저 함수 객체 [[Scope]]의 내부 속성에 있는 객체들을 순서대로 스코프 체인에 복사합니다.
2. 둘째, 함수가 실행되면 새로운 활성화 개체 개체가 생성됩니다. 이 개체에는 이에 대한 정의, 매개 변수(인수) 및 로컬 변수(이름이 지정된 매개 변수 포함)가 포함됩니다. . 도메인 체인의 앞부분입니다.
JavaScript 코드 실행 중 식별자가 발견되면 식별자 이름을 기준으로 실행 컨텍스트(Execution Context)의 범위 체인에서 검색됩니다. 범위 체인의 첫 번째 개체(함수의 활성화 개체)부터 시작하여 찾을 수 없는 경우 범위 체인에서 다음 개체를 검색하는 식으로 식별자 정의를 찾을 때까지 계속됩니다. 검색 후 범위의 마지막 개체인 전역 개체를 찾을 수 없으면 오류가 발생하고 사용자에게 변수가 정의되지 않았다는 메시지가 표시됩니다. 이는 ECMA-262 표준에 설명된 함수 실행 모델 및 식별자 확인(식별자 확인) 프로세스입니다. 실제로 대부분의 JavaScript 엔진이 이러한 방식으로 구현되는 것으로 나타났습니다. ECMA-262는 이 구조의 사용을 의무화하지 않고 기능의 이 부분만 설명한다는 점에 유의해야 합니다.
식별자 확인(식별자 확인) 프로세스를 이해한 후에는 검색 프로세스가 크게 단축되기 때문에 지역 변수가 다른 범위의 변수보다 더 빠르게 확인되는 이유를 이해할 수 있습니다. 하지만 얼마나 더 빨라질까요? 이 질문에 답하기 위해 다양한 범위 깊이에서 변수의 성능을 테스트하는 일련의 테스트를 시뮬레이션했습니다.
첫 번째 테스트는 변수에 가장 간단한 값을 쓰는 것입니다(여기서는 리터럴 값 1이 사용됨). 결과는 아래 그림에 표시되어 있으며 이는 매우 흥미롭습니다.
식별자 파싱 과정에서 심층 검색이 필요한 경우 성능 손실이 발생하며, 식별자 깊이가 커짐에 따라 성능 손실 정도가 증가한다는 것을 결과에서 확인하는 것은 어렵지 않습니다. 당연히 Internet Explorer의 성능이 가장 나빴습니다(그러나 공정하게 말하면 IE 8에서는 약간의 개선이 있었습니다). 여기에는 몇 가지 예외가 있다는 점은 주목할 가치가 있습니다. Google Chrome과 최신 Midnight 버전의 WebKit은 변수에 대한 액세스 시간이 매우 안정적이며 범위 깊이가 증가해도 증가하지 않습니다. 물론 이는 그들이 사용하는 차세대 JavaScript 엔진인 V8 및 SquirrelFish에 기인합니다. 이러한 엔진은 코드를 실행할 때 최적화를 수행하며, 이러한 최적화를 통해 이전보다 더 빠르게 변수에 액세스할 수 있다는 것은 분명합니다. Opera도 IE, Firefox 및 현재 버전의 Safari보다 훨씬 빠르지만 V8 및 Squirrelfish 기반 브라우저보다는 느립니다. Firefox 3.1 Beta 2의 성능은 조금 의외입니다. 로컬 변수의 실행 효율은 매우 높지만, 스코프 레이어 수가 늘어나면서 효율성이 크게 떨어집니다. 여기서는 기본 설정을 사용하고 있는데 이는 Firefox에 추적 기능이 켜져 있지 않음을 의미합니다.
위의 결과는 변수에 쓰기 작업을 수행하여 얻은 결과입니다. 실제로 변수를 읽을 때 상황이 다를지 궁금해서 다음과 같은 테스트를 수행했습니다. 읽기 속도가 쓰기 속도보다 약간 빠른 것으로 나타났으나 성능 변화 추세는 일관되게 나타났다.
이전 테스트와 마찬가지로 Internet Explorer와 Firefox는 여전히 가장 느렸으며 Opera는 매우 눈길을 끄는 성능을 보여주었습니다. 마찬가지로 Chrome과 최신 버전의 Webkit Midnight Edition도 범위 깊이와 관련이 없는 성능 추세를 보여주었습니다. 주목할 가치가 있습니다. 예, Firefox 3.1 베타 2의 가변 액세스 시간은 여전히 깊이에 따라 이상한 변화를 보입니다.
테스트 중에 Chrome에서 전역 변수에 액세스할 때 추가 성능 손실이 발생한다는 흥미로운 현상을 발견했습니다. 전역 변수에 접근하는 시간은 범위 수준과 관련이 없지만, 같은 수준의 지역 변수에 접근하는 시간보다 50% 더 길어집니다.
이 두 가지 시험은 우리에게 어떤 깨달음을 가져다 줄 수 있습니까? 첫 번째는 지역변수를 최대한 활용하겠다는 기존 관점을 검증하는 것이다. 모든 브라우저에서 지역 변수에 액세스하는 것이 전역 변수를 포함하여 범위 전체에 걸쳐 변수에 액세스하는 것보다 빠릅니다. 이 테스트를 통해 얻은 경험은 다음과 같습니다.
* 함수에 사용된 모든 변수를 주의 깊게 확인하십시오. 현재 범위에 정의되지 않고 두 번 이상 사용되는 변수가 있는 경우 이 변수를 지역 변수, 이 지역 변수를 사용하여 읽기 및 쓰기 작업을 수행합니다. 이는 범위 외부의 변수 검색 깊이를 1로 줄이는 데 도움이 될 수 있습니다. 이는 전역 변수에 특히 중요합니다. 왜냐하면 전역 변수는 항상 범위 체인의 마지막 위치에서 검색되기 때문입니다.
* with 문을 사용하지 마세요. 실행 컨텍스트(Execution Context)의 범위 체인을 수정하고 앞에 개체(Variable Object)를 추가하기 때문입니다. 이는 with를 실행하는 동안 실제 지역 변수가 범위 체인의 두 번째 위치로 이동하여 성능 손실이 발생함을 의미합니다.
* 코드 조각이 확실히 예외를 발생시킬 것이라고 확신하는 경우에는 try-catch를 사용하지 마십시오. catch 분기는 with와 동일한 범위 체인에서 처리되기 때문입니다. 하지만 try 분기 코드에서는 성능 손실이 없으므로 여전히 try-catch를 사용하여 예측할 수 없는 오류를 잡는 것이 좋습니다.
이 주제에 관해 더 많은 토론을 원하신다면 지난 달 Mountain View JavaScript Meetup에서 제가 작은 강연을 드린 적이 있습니다. SlideShare에서 슬라이드를 다운로드하거나 내 강연 11분쯤에 시작되는 파티의 전체 비디오를 시청할 수 있습니다.
번역가의 메모:
이 글을 읽으면서 의문이 든다면 다음 두 글을 읽어 보시기 바랍니다.
* Richie가 작성한 "JavaScript 객체 모델-실행 모델"
* "ECMA-262 Third Edition"에서는 Execution Context인 Chapter 10을 중심으로 이 글에서 언급된 용어들을 자세히 설명하고 있다.
마지막에 Nicholas는 Mountain View JavaScript Meetup에 대해 언급했습니다. Meetup 웹사이트는 실제로 다양한 실제 활동을 위한 조직 웹사이트입니다. 캘리포니아에 사는 것은 정말 좋은 일입니다. 참여할 수 있는 활동. 헤헤.