[javascript] var가 let보다 빠르다? 왜 빠른가.

[javascript] var가 let보다 빠르다? 왜 빠른가.

0. var가 let보다 빠르다고들 한다.

모 프로젝트로부터 헬퍼 요청이 있어서 2주 정도 단기로 투입됐을 때,

코드를 분석하며 의아했던 점 중에 하나는 대부분의 변수가 var로 선언되어있다는 것이었다.

코드를 살펴봤을 때, let을 두고 var를 사용할 이유가 없어보였기에

해당 로직을 개발하신 분께 여쭤봤더니 아래와 같은 답변을 들을 수 있었다.

"var가 let보다 빨라요"

사실 당시엔 그런가보다, 하고 넘겼다.

왜 var가 let보다 빠르다는건지에 대한 설명이 부족했지만,

오픈직전의 프로젝트에 헬퍼로 투입된 입장에서 이미 동작하고 있는 로직의 변수선언을 왜 var로 했는지 리뷰하며 수정을 요청드릴 정도로 정신머리가 있지는 았았다.

...물론, 급할수록 돌아가랬다고 변명이다. 개발자로써 직무유기랄까.

그러다 얼마전에 팀원분이 개발하던 것을 이어받게되어 코드 분석을 하고 있는데,

그 코드들에도 let보다는 var가 대부분의 변수 선언을 담당하고 있었다.

그리고 왜 let대신 var를 쓰셨냐는 질문에 돌아온 대답은 역시나,

"var가 let보다 빨라"

왜 아무도 왜 그런지 왜 말을 안 해주는거야, 왜에ㅠㅠㅠ

...그래서 왜 var가 let보다 빠르다고들 하는건지 직접 찾아보기로 했다.

1. 구글은 정답을 알고있다.

이런 쪽으로의 궁금증은 개발자라면 누구나 품을 수 있는 거라고 생각한다.

그리고 그걸 반증하듯, 이미 Stack overflow에는 관련한 질문들이 여럿있었다.

예를 들어...why var declaration fast than let 와 같은 질문이라던가

let vs var performance in nodejs and chrome 라던가

Why is let slower than var in a for loop in nodejs? 라던가.

그리고 해당 질문들은, 본인들이 테스트해보니 아래와 같이 var가 let보다 빠르다는 명확한 기록을 남김으로써, 자신들의 주장에 신빙성을 더해주고 있었다.

각 질문들에 있는 데이터들. var가 let보다 빠른 것을 분명하게 알 수 있다.

예제를 바탕으로 실측된 위와 같은 값들을 바탕으로 var가 let보다 빠르다는 것을 확인할 수는 있었지만...궁극적으로 내가 찾던 답은 이게 아니었다. 내가 찾던 것은 '아, 진짜 빠르구나'라는 결론이 아니라 '그래서 왜 빠른가'에 대한 과정의 설득성이었고, 이에 가장 근접한 내용을 한 블로그에서 찾을 수 있었다.

A Lexical Environment is a specification type used to define the association of Identifiers to specific variables and functions based upon the lexical nesting structure of ECMAScript code. (중략) Usually a Lexical Environment is associated with some specific syntactic structure of ECMAScript code such as a FunctionDeclaration, a BlockStatement, or a Catch clause of a TryStatement and a new Lexical Environment is created each time such code is evaluated.

(발번역 주의) 렉시컬 환경은 ECMAScript 코드의 렉시컬 중첩구조를 기반으로 식별자(identifier)와 특정 변수 및 함수와의 연관성을 정의하기 위한 스펙 유형이다. 렉시컬 환경은 일반적으로 Function Declaration, Block Statement, try구문의 catch 절과 같은 ECMAScript 코드의 특정 구문 구조와 연결되며, 이러한 코드가 평가될 때마다 새로운 렉시컬 환경이 생성된다.

- 출처 : let과 var의 성능 비교

위 문구는 해당 블로거분이 ECMAScript2015 Specfication - Lexical Environments 에서 발췌한 것으로써, 친절하게 번역까지 해주신 내용을 발췌한 것이다. 저기서 설명된 Lexical Environment는 예전에 내가 포스팅했던 [Javascript] class도 호이스팅이 되나요(feat. lexical environment) 에서도 언급됐던 내용인데, Javascript의 Execution Context(실행 컨텍스트)가 구축될 때 해당 영역에서 사용되는 변수 혹은 함수들이 선정의되는 자료구조라고 보면 된다.

그리고 당연하게도 이때 할당되는 변수나 함수들은 본인들의 scope를 기준으로 Lexical Environment에 할당이 될텐데...let과 const의 경우 Block scope를 가지고 있기 때문에 if나 for와 같이 지정된 Block 영역내에서 활용될 경우 새롭게 생성되는 Lexical Environment에서 시스템적인 비용이 발생한다는 것이다. 반면에 Functional Scope를 가지는 var는 이러한 비용적인 측면에서 자유롭기에, Block Scope를 가진 let/const보다 빠르다는 결론에 도달할 수 있는 것이다.

그리고, 실제로 결과로도 그러하다는 것을 Stackoverflow의 질문들과 위 포스팅에 첨부된 결과값으로 우리는 확인 할 수 있었다.

2. 끝날때까진, 끝난게 아니다.

여기서 아름답게, var가 let보다 빠르구나! 라고 박수치고 끝났으면 참 좋았을텐데.

끝날때까진, 끝난 게 아니다.

앞서 Stackoverflow와 let과 var의 성능 비교 블로그의 설명을 바탕으로, 나는 설득을 당했고.

이 포스팅을 마무리지으려고 했었다. 그렇게 마무리됐다면 참 좋았을텐데...

이게 또 Stackoverflow와 블로그에서 실측되는 예제 코드를 봤으니, 보는걸로 끝맺는게 아니라 실제로 동작시켜보는게 개발자로써의 인지상정 아니겠는가. 그리고, 해당 코드 스니펫들을 동작시켜보는순간...

왜, 나는 별 차이가 없어...??

다시 이 짤을 쓰는 순간이 오게 될 줄이야.

심지어, 내가 설득당했던 let과 var의 성능 비교 블로그의 예제코드도 돌려보니

Edge, Chrome, Firefox에서의 결과

각 케이스별로 크게 차이가 나지 않음은 물론이고 일부 구간에선 let이 var보다 빠른 결과를 보이고 있었다.

from http://blinders.tistory.com/101 by ccl(S) rewrite - 2021-10-15 00:00:21