https://wormwlrm.github.io/2019/12/04/Why-JSON-parse-is-faster-than-object-literal.html
왜 JSON.parse가 더 빠를까?
최근에 처음 깨달은 사실인데, JSON.parse("{}")로 객체를 만드는 것이 쉽다고 한다.
그 이유는 자바스크립트 엔진에게 있어서, JSON을 분석하는 것이 매우 간단하기 떄문이라고 한다.
오오 너무 신기하다.
자바스크립트는 문맥에 민감하기 때문에 {}를 파싱하는 것에 여러가지 신경을 써야하고,
Number, String, Boolean, Array, Object 등등의 리터럴들에 대한 대비를 해야한다. (토큰이라고 하는듯)
하지만 JSON.parse("{}")으로 객체를 생성한다고 하면 String 토큰만 있으면 된다.
실제로 약 1.7배 속도 차이가 난다고 한다.
그럼 항상 JSON.parse로 생성하는 것이 좋을까?
하지만 항상 이렇게 객체를 생성하면 좋은것인지에 대한 생각을 해보니, 그것은 또 아닌것같다.
JSON.parse로 파싱을 하는 문자열은 어떤 객체에 JSON.stringify를 적용한것과 같다.
근데 JSON.stringify에는 Date나 Symbol이나 undefined, 순환객체같은 것들을 직렬화 하지 못한다는 단점이 있을 것이므로, 객체를 만드는 것에대한 유연성이 떨어질 것 같다는 생각을 했다.
그래서 위 처럼 직렬화하지 못하는 프로퍼티가 있는 경우를 제외하고는 JSON.parse로 변환시켜주는 것이 최선이라고 생각한다.
관련 라이브러리가 있는데 https://github.com/nissy-dev/babel-plugin-object-to-json-parse/blob/main/src/utils.ts
뜯어보니까, 역시나 utils에 converter코드를 보니 isvalidJsonValue라는 함수로 체크하고 있었다.
순환객체 같은 경우는 재귀적으로 풀고 있는것 보니, 아주 대응이 잘된 라이브러리같다는 느낌을 받았다.
앞으로 성능 최적화를 할때 이 라이브러리를 한번 써보고 측정해봐야겠다!
유레카!
'개발 > FrontEnd Interview' 카테고리의 다른 글
default export 와 named export의 차이점 (0) | 2021.12.01 |
---|---|
redux-saga가 해결하고자 하는 것 (0) | 2021.11.30 |
javascript class를 funcition으로 변환해보기 (0) | 2021.11.17 |
IIFE와 arrow function (0) | 2021.11.16 |
Virtual DOM의 진짜 역할은 뭐지? (0) | 2021.11.09 |