사이트를 카카오톡, 페이스북 등 SNS에서 공유할 때 이른바 썸네일이 보이게 하기 위해서는 [open graph tool](https://ogp.me/)를 사용해야 한다. 트위터의 경우에는 자체 정의된 `twitter:*` 시리즈의 무언가를 이용해야 한다. 내 모든 블로그 글에 이쁜 대문 이미지가 있으면 좋겠지만, 모든 것에 현실적으로 이미지를 만드는 것은 불가능하고 귀찮다. 그래서 주어진 이미지에 블로그의 메타 정보를 쓰는 방식으로 정적 이미지를 만든 다음, 이 이미지를 공유용 이미지로 서빙하는 방법에 대해서 고민해 보았다.

## 구성

og tag image 주소 요청 > 해당 주소로 cloudinary에 이미지가 있는지 확인

- 있다면 그 주소로 리다이렉트
- 없다면 > 블로그에 이미지 형태로 준비되어 있는 페이지 방문 > 해당 페이지 스크린샷 > 스크린샷 한 이미지를 cloudinary에 업로드 > 해당 이미지 주소로 리다이렉트

## 1. 정적인 이미지를 만들 페이지 구성하기

`/generate-screenshot`이라는 이름으로 페이지를 하나 만들고, 거기에 정적으로 생성할 이미지를 일단 웹페이지 형태로 만들어보았다.

https://yceffort.kr/generate-screenshot?tags=javascript&title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions

https://github.com/yceffort/yceffort-blog-v2/blob/master/pages/generate-screenshot.tsx

여기저기 글을 본 결과 최적의 사이즈는 `1200x630`으로 알려져 있으며, 해당 사이즈에 맞게 페이지를 구성하면 된다.

## 2. 해당 페이지를 스크린샷 찍기

이제 해당 페이지를 방문해서 스크린샷을 찍어야 한다. 첫 번째로 시도한 것은 [nextjs에 api를 활용하여 vercel에서 시도하는 것](https://nextjs.org/docs/api-routes/introduction)이었다. 그러나 결과적으로 이 시도는 실패했는데, 일단 스크린샷을 찍기 위해서는 puppetter의 headless chrome instance를 띄워야 하는데 이 메모리가 생각보다 많이 들었다. 그리고 별개의 폰트도 설치해야 하는데 그 과정까지 vercel에서 할 수 없었으므로, [firebase functions](https://firebase.google.com/docs/functions)을 활용하기로 했다.

시작하는 방법은 [여기](https://firebase.google.com/docs/functions/get-started)에 잘 나와있다. 심지어 한글로 되어 있다.

```javascript
exports.screenshot = functions.https.onRequest(async (req, res) => {
 const query = req.query
 const title = encodeURI(query.)
 const firebaseTitle = title.replace(/\//gi, '-')
 const screenshotRef = db.collection('screenshot')

 const exist = await screenshotRef.doc(firebaseTitle).get()

 if (exist.exists) {
 return res.redirect(exist.data().url)
 }

 try {
 const postUrl = `http://yceffort.kr/generate-screenshot?${queryString.stringify(
 query,
 )}`
 const screenshot = await takeScreenshot(postUrl)
 const uploadedImage = await putImage(title, screenshot)
 screenshotRef.doc(firebaseTitle).set({
 url: uploadedImage,
 })
 res.redirect(uploadedImage)
 } catch (e) {
 console.error(e)
 res.json({ error: e.toString() })
 }
})
```

```javascript
const takeScreenshot = async function (url) {
 const chromiumPath = await chromium.executablePath

 const browser = await chromium.puppeteer.launch({
 executablePath: chromiumPath,
 args: chromium.args,
 defaultViewport: chromium.defaultViewport,
 headless: chromium.headless,
 })

 const page = await browser.newPage()
 await page.setViewport({ height: 630, width: 1200 })
 await page.goto(url)
 const buffer = await page.screenshot({ encoding: 'base64' })
 await browser.close()
 return `data:image/png;base64,${buffer}`
}
```

여기서 겪은 삽질을 몇가지 소개해본다.

### 1) puppeteer는 무겁다

puppeteer를 npm install 로 설치해보면 꽤 시간이 걸린다는 것을 알 수 있다. 그래서 `puppeteer`를 `puppeteer-core`만 설치하고, cloud function에서 쓸 수 있는 다른 chromium 브라우저를 알아 봐야 한다. 그래서 https://github.com/alixaxel/chrome-aws-lambda 를 설치했다. 그리고 `iltorb` 도 함께 설치해 주어야 한다.

### 2) react metatag의 query escape

원래는 이 주소를 넘겼다.

https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&tags=javascript&title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions

그러나 소스 보기로 해당 주소를 보면 아래와 같이 되어 있었다.

```html
<meta
 property="og:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

`&`가 `&amp;`로 escape 처리 되어 있는 것이다.

- https://github.com/facebook/react/issues/13838
- https://github.com/vercel/next.js/issues/2006

두가지 선택이 있었는데, query param 구조로 되어 있는 주소를 path variable 로 모두 바꾸거나, 혹은 받는 쪽에서 처리를 하는 것이다. path를 다 바꾸기는 넘 귀찮아서 아래와 같은 처리를 추가해주었다.

```javascript
const query = Object.keys(context.query).map(
 (key) => (query[key.replace(/amp;/, '')] = context.query[key]),
 ) as any
```

### 3) 느린 속도

스크린샷을 찍고, 이미지를 업로드 해서 내려주는 최초의 과정은 느릴 수 밖에 없다.그러나 문제는 두번째 과정 이후 부터 있었다. 이미 이미지가 생성되었는지 확인하기 위해 cloudinary에 get 요청을 날리는데, 이 과정 또한 쓸데 없이 오래 걸렸다. 그래서 cloudinary에 찔러서 확인하는대신, 한번 생성된 이미지는 key와 value 형태로 주소를 firebase에 저장해 두어 더 빠르게 내려주었다.

저장

```javascript
const uploadedImage = await putImage(title, screenshot)
screenshotRef.doc(firebaseTitle).set({
 url: uploadedImage,
})
```

불러오기

```javascript
const exist = await screenshotRef.doc(firebaseTitle).get()

if (exist.exists) {
 return res.redirect(exist.data().url)
}
```

그렇다고 해서 속도문제가 완전히 해결된 것은 아니었다. 첫단계에서는 여전히 생성속도가 느리고, 주소에서 느껴지겠지만, 미국 동부를 거쳐서 왔다리 갔다리 해야 하기 때문에 여전히 좀 답답한면이 있다.

## 3. 메타 태그에 심기

```html
<meta
 property="og:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

```html
<meta
 name="twitter:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

## 결과

![preview1](./images/metadata-preview1.png)

![preview2](./images/metadata-preview2.png)

## 문제점

- 여전히 좀 느리다. 당연히, 초기 생성단계에서는 느릴 수 밖에 없다. 이것을 어떻게 해결할 것인가가 관건이다. 글이 올라간 뒤에, github action으로 트리거 해서 생성할 것인가? 혹은 배포 단계에 이를 포함할 것인가?
- firebase functions, firebase storage, 거기에 cloudinary까지 사용하고 있다. 코로나 시대에 줄어든 용돈으로, 과연 여기까지 커버할 수 있을 것인가? vercel은 언제 또 나에게 pro 버전으로 내 지갑을 재차 노릴 것인가?

참으로 무시무시한 일이 아닐 수 없다.

서버리스로 블로그 포스트 썸네일 생성하기

## Table of Contents

## `Performance.now`

Performance API는 `performance.now()`를 통해서 [DOMHighResTimeStamp](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)에 접근할 수 있게 해준다. `performance.now()`는 페이지를 로드한 이후로 지난 ms를 보여준다. 최대 정밀도는 `5µs`정도다.

```javascript
const t0 = performance.now()
for (let i = 0; i < array.length; i++) {
 // some code.......
}
const t1 = performance.now()
console.log(t1 - t0, 'milliseconds')
```

`Chrome`

```bash
0.6350000001020817 "milliseconds"
```

`Firefox`

```bash
1 milliseconds
```

Chrome 과 Firefox 의 결과에 조금 차이가 있는 것을 볼 수 있는데, 이는 Firefox가 60버전 이후로 performance API의 정밀도를 2ms 정도로 조정했기 때문이다.

Performance API는 이외에도 다양한 기능을 제공하는데, [여기](https://blog.logrocket.com/how-to-practically-use-performance-api-to-measure-performance/)에tj 확인 가능하다.

### `Date.now`를 써도 되지 않을까?

물론 이것도 가능하지만, 약간의 차이가 있다.

`Date.now`는 마찬가지로 ms를 리턴하는데, 이는 시스템의 시간에서 Unix epoch(1970-01-01T00:00:00Z)의 차이를 리턴한다. 이는 부정확할 뿐만 아니라, 항상 증가한다고도 볼 수 없다.

> System time을 기반으로한 Date를 기준으로 실제 사용자를 모니터링하는 것은 적절치 않다. 대부분의 시스템은 정기적으로 시간을 동기화 하는 데몬을 실행한다. 그리고 그 시계는 15분 내지 20분 마다 몇 ms 씩 조정되는 것이 일반적이다. 따라서 그 속도에서 측정된 10 초간격의 1% 정도가 부정확할 것이다.

> Perhaps less often considered is that Date, based on system time, isn't ideal for real user monitoring either. Most systems run a daemon that regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.

출처: https://developers.google.com/web/updates/2012/08/When-milliseconds-are-not-enough-performance-now

## `Performance.mark` and `Performance.measure`

`Performance.now` 외에도 코드의 여러 지점에서 시간을 특정하고, 이를 [Webpagetest](https://felixgerschau.com/custom-metrics-webpagetest/)와 같은 성능 테스트 도구세어 사용자 지정 메트릭으로 사용할 수 있는 몇가지 다른 함수들이 존재한다.

### `Performance.mark`

이름에서 느껴지는 것 처럼, 코드 내에서 마킹을 할 수 있는 용도다.이 마크는 performance buffer에서 timestamp를 생성하여 나중에 코드의 특정 부분을 실행하는데 걸린 시간을 측정하는데 사용 가능하다.

마킹을 생성하기 위해서는, string을 파라미터로 함수를 호출해야 하며, 이 string은 나중에 식별자 용도로 사용된다. 마찬가지로 최대 정밀도는 `5µs`정도다.

```javascript
performance.mark('name')
```

- detail: null
- name: "name"
- entryType: "mark"
- startTime: 268528.33999999985
- duration: 0

### `Performance.measure`

이 함수는 1~3개의 arguments를 받는다. 첫번째 인수는 `name`이고, 나머지는 측정하고 싶은 마킹 영역을 넣으면 된다.

네비게이션 시작부터 측정

```javascript
performance.measure('measure name')
```

네비게이션 시작부터 특정 마킹 까지

```javascript
performance.measure('measure name', undefined, 'mark-2')
```

특정 마킹 부터 바킹까지

```javascript
performance.measure('measure name', 'mark-1', 'mark-2')
```

마킹 부터 지금까지

```javascript
performance.measure('measure name', 'mark-1')
```

## 측정 값 수집

### `performance entry buffer`로 부터 데이터 수집

이전 부터 계속 측정 결과가 `performance entry buffer` 에 수집된다고 언급했는데, 이제는 여기에 접근하여 값을 가져오는 방법을 알아보고자 한다.

이를 위해 performance API는 3종류의 api를 제공한다.

- `performance.getEntries()`: `performance entry buffer`에 저장된 모든 것을 보여준다.
- `performance.getEntriesByName('name')`
- `performance.getEntriesByType('type')`: 특정 타입에 대해서만 보여준다. `measure`, `mark`만 가능

모든 예제를 종합하자면, 대략 아래와 같은 코드가 만들어 질 것이다.

```javascript
performance.mark('mark-1')
// 성능을 측정할 코드...........
performance.mark('mark-2')
performance.measure('test', 'mark-1', 'mark-2')
console.log(performance.getEntriesByName('test')[0].duration)
```

## `console.time`

단순히 `console.time`을 호출하고, 측정 종료 시점에 `console.timeEnd`를 호출하면 된다.

```javascript
console.time('test')
for (let i = 0; i < array.length; i++) {
 // some code
}
console.timeEnd('test')
```

`chrome`

```bash
test: 0.766845703125ms
```

`firefox`

```bash
test: 2ms - timer ended
```

다른 API 대비 사용하기 간단하고, 수동으로 비교를 하지 않아도 알아서 비교를 해준다는 장점이 있다.

## 시간 정확도

당연한 이야기 이지만, 여러 브라우저에서 성능을 측정하다보면 결과가 다르다는 것을 눈치 챌 수 있다. 이는 브라우저가 [타이밍 공격](https://en.wikipedia.org/wiki/Timing_attack)과 [핑거프린팅](https://pixelprivacy.com/resources/browser-fingerprinting/) 등의 공격기법으로 부터 유저를 보호하기 위해서다. 이 시간이 너무나도 정확하다면, 해커는 사용자를 간단하게 식별할 수 있을 것이다.

앞서 언급한 이유 때문에, 60버전이후의 Firefox에서는 이러한 정확도를 최대 2ms정도로 감소 시켰다.

## 유념해야 할것

### 분할해서 살펴볼 것

단순히 코드의 어떤 부분이 느린지 엉뚱하게 추측하지 말고, 위에서 언급한 기능들을 사용하여 각각 나눠서 정밀하게 측정하자. 느린부분을 찾기 위해, 느린 코드 블록 주위에 `console.time`을 배치하자. 그 다음, 각부분의 성능을 측정하자. 만약 어떤 부분이 다른 부분보다 느리다는 것을 알아넀다면, 계속 나아가서 병목현상을 일으키는 부분을 찾을 때 까지 더 깊이 들어가자.

### 입력 값에 주의를

실제 애플리케이션에서는, 함수의 입력 값에 따라 결과가 많이 달라질 수 있다. 단순히 함수의 랜덤 값으로 테스트 할 것이 아니라, 실제로 사용되는 예제를 바탕으로 측정하는 것이 좋다.

### 함수를 여러번 실행하자.

배열을 순회하는 함수 내에서, 각각의 원소값을 계산하고 그 결과를 배열로 리턴하는 함수가 있다고 가정해보자. `forEach`와 `for`중에 무엇이 더 성능에 우위가 있을지 알아보고 싶을 것이다.

```javascript
function testForEach(x) {
 console.time('test-forEach')
 const res = []
 x.forEach((value, index) => {
 res.push((value / 1.2) * 0.1)
 })

 console.timeEnd('test-forEach')
 return res
}

function testFor(x) {
 console.time('test-for')
 const res = []
 for (let i = 0; i < x.length; i++) {
 res.push((x[i] / 1.2) * 0.1)
 }

 console.timeEnd('test-for')
 return res
}
```

```javascript
const x = new Array(100000).fill(Math.random())
testForEach(x)
testFor(x)
```

파이어 폭스에서 실행한다면 대략 이런 결과가 나올 것이다.

```bash
test-forEach: 4ms - 타이머 종료됨
test-for: 2ms - 타이머 종료됨
```

`forEach`가 더 느린가? 🤔 싶지만 여러번 하게 되면

```bash
test-forEach: 4ms
test-forEach: 3ms
test-for: 2ms
test-for: 1ms
```

별반 차이가 없음을 알수 있다.

### 그리고 다양한 브라우저에서

똑같은 짓을 크롬에서 해보자.

```bash
test-forEach: 5.589111328125 ms
test-forEach: 5.730712890625 ms
test-for: 4.765869140625 ms
test-for: 6.64892578125 ms
```

firefox와 chrome 은 서로 다른 자바스크립트 엔진을 가지고 있고, 이는 성능 최적화에도 차이가 있다. 이 경우, 같은 input 기준으로 firefox에서 보다 최적화를 잘하고 있음을 볼 수 있다. 그리고 두 엔진 모두에서 `forEach`보다는 `for`가 나은 것을 볼 수 있다. (유의미한 차이라고 볼 수 있을지는 모르겠지만)

따라서 성능 측정은 한브라우저에서 할 것이 아니라, 가능한 많은 모던 브라우저에서 해봐야 한다.

### CPU 스로틀링

항상 내가 개발하고 있는 컴퓨터는 대부분의 사용자가 사용하는 모바일 환경보다 더 빠르다는 것을 염두해 두어야 한다. 브라우저별로 CPU 성능을 쓰로틀 해주는 기능을 가지고 있으므로, 이를 활용해서 테스트 해야 한다.

- https://developers.google.com/web/updates/2017/07/devtools-release-notes#throttling

사실 실전에서 해본적은 거의 없음 😇

자바스크립트 함수의 성능 측정하기

Datetime을 다루는 것은 분명 쉬운 일은 아니다. 한참 vanilla 자바스크립트에 취해 있을 때, least library challenge(?)의 일환으로 datetime을 내재화 해서 관리하곤 했지만 이는 분명 어려운 일이었다. 그 때 마다 결국 가장 익숙한 moment로 돌아와서 하곤 했는데, 언젠가 bundle 분석을 한 뒤로 moment에 대한 사용을 조금 꺼리기 시작했다. moment는 내가 쓰는 기능 대비 정말 큰 용량을 차지하고 있었다. (timezone을 제외 하더라도) 분명 내가 moment의 좋은 기능을 쉽게 사용하는 면도 있었지만, 조금이라도 더 빠른 애플리케이션을 사용하기 위해서는 moment 외에 다른 대안이 필요했다.

그러던 중, [moment 가 deprecated 된다는 소식을 알려왔다.](https://momentjs.com/docs/)

> ... The modern web looks much different these days. Moment has evolved somewhat over the years, but it has essentially the same design as it did when it was created in 2011. Given how many projects depend on it, we choose to prioritize stability over new features.

조금 많이 뒷북이긴 하지만, 왜 moment가 역사 속으로 사라졌는지 몇가지 이유를 짚고 넘어가고자 한다.

## 1. 느리다

단도직입적으로 그래프를 통해서 알수 있다. 다른 datetime library 대비 속도가 많이 느렸다.

![speed1](https://raygun.com/blog/wp-content/uploads/2017/09/image4-2.png)

![speed2](https://raygun.com/blog/wp-content/uploads/2017/09/image3.png)

![speed3](https://raygun.com/blog/wp-content/uploads/2017/09/image1.png)

출처: https://raygun.com/blog/moment-js-vs-date-fns/

뭐 여러가지 이유가 있겠지만, regex를 주로 쓰는 moment에 대비 다른 라이브러리들은 `Z`로 끝나면 `new Date(string)`을 쓴다던지, 혹은 느린 regex 대신에 자체적으로 개발한(?) `if` 와 `charAt` 등을 쓴다던지 다양한 노력들을 하고 있었다. regex를 파싱해서 이해하는 작업은 확실히 느리다.

## 2. 무겁다

![size-of-datetime-libraries](./images/size-of-datetime-libraries.png)

출처: https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js

https://github.com/jmblog/how-to-optimize-momentjs-with-webpack

기본적으로 momentjs는 232kb, (gzip시 66kb) 이며, webpack으로 locale을 제거할 경우 사이즈는 68kb (gzip시 23kb) 까지 떨어진다. 그리고 더이상의 tree shaking은 불가능하다. js-joda가 제법 크긴 하지만 기간과 타임존까지 기본으로 제공하는 라이브러리라는 것을 알아둬야 한다. 그리고 나머지 라이브러리들은 트리쉐이킹이 가능하다.

## 3.mutable이다.

이는 moment 공식 가이드에서도 언급한 문제다.

> As an example, consider that Moment objects are mutable. This is a common source of complaints about Moment. We address it in our usage guidance but it still comes as a surprise to most new users. Changing Moment to be immutable would be a breaking change for every one of the projects that use it. Creating a "Moment v3" that was immutable would be a tremendous undertaking and would make Moment a different library entirely. Since this has already been accomplished in other libraries, we feel that it is more important to retain the mutable API.

https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js

```javascript
const startedAt = moment()
const endedAt = startedAt.add(1, 'year')

console.log(startedAt) // > 2020-02-09T13:39:07+01:00
console.log(endedAt) // > 2020-02-09T13:39:07+01:00
```

`moment`를 조작하는 모든 method 들은 리턴 값과 참조값 모두를 바꿔 버리기 때문에, 에러를 만들 소지가 높다.

## 4. 디버깅이 어렵다.

`moment`안에 파라미터를 넣는 것은 좋은 아이디어이긴하지만, 그 안에 따라서 동작이 매우 일관적이지 못하다. 예를 들어, moment 안에 잘못된 값을 넣었을 경우 에러가 나는게 아니라 그냥 현재 시간이 나와버릴 수도 있다.

```javascript
moment().format() // > 2019-02-08T17:07:22+01:00
moment(undefined).format() // > 2019-02-08T17:07:22+01:00
moment(null).format() // > Invalid date
moment({}).format() // > 2019-02-08T17:07:22+01:00
moment('').format() // > Invalid date
moment([]).format() // > 2019-02-08T17:07:22+01:00
moment(NaN).format() // > Invalid date
moment(0).format() // > 1970-01-01T01:00:00+01
```

요약하자면, `undefined`는 가능하지만, `null` `''`, `NaN`은 안된다.

## 결국

lighthouse에서도 에러가 뜨고

![lighthouse warning](https://pbs.twimg.com/media/EhM0XE3UwAA2Co5?format=jpg&name=medium)

https://twitter.com/addyosmani/status/1304676118822174721

moment를 최적화 하는 방법까지도 알려지기 시작했다.

https://github.com/GoogleChromeLabs/webpack-libs-optimizations#moment

## 대안

사이즈가 중요한 프론트엔드의 경우 `date-fns`나 `day.js`가 좋다. 그 외의 경우에는 기능이 가장 리치한 `js-joda`를 사용하는 것이 좋다.

|          | size   | size(gzip) | speed(to) | tree-shaking | immutable | throw error | timezone |
| -------- | ------ | ---------- | --------- | ------------ | --------- | ----------- | -------- |
| moment   | 232/68 | 66/26      | 16.527    | X            | X         | X           | O        |
| day.js   | 6      | 3          | 9.129     | X            | O         | X           | X        |
| luxon    | 64     | 18         | 15.406    | X            | O         | O           | O        |
| js-joda  | 208    | 39         | 11.397    | X            | O         | O           | O        |
| date-fns | 30     | 7          | 5.175     | O            | O         | X           | X        |
| native   |        |            | 1.297     |              | X         | X           | X        |

출처: https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js#fnref2

그럼에도, 저렇게 큰 라이브러리 자체를 deprecated 시킬 수 있다는 것 만으로도 자바스크립트 생태계가 건강하게 나아가고 있다는 방증인 것 같다. 여전히, 많은 수의 프로젝트가 moment에 의존하고 또 그 편리함에 많은 도움을 얻었다. moment가 이야기 한 `modern web looks much different these days` 처럼, 이제는 다른 라이브러리를 쓸 때가 왔다. 그리고 나 또한, 오래되고 낡은 코드를 과감하게 deprecated 시킬 용기가 필요하다.


왜 moment 는 deprecated 되었을까

Datetime을 다루는 것은 분명 쉬운 일은 아니다. 한참 vanilla 자바스크립트에 취해 있을 때, least library challenge(?)의 일환으로 datetime을 내재화 해서 관리하곤 했지만 이는 분명 어려운 일이었다. 그 때 마다 결국 가장 익숙한 moment로 돌아와서 하곤 했는데, 언젠가 bundle 분석을 한 뒤로 moment에 대한 사용을 조금 꺼리기 시작했다. moment는 내가 쓰는 기능 대비 정말 큰 용량을 차지하고 있었다. (timezone을 제외 하더라도) 분명 내가 moment의 좋은 기능을 쉽게 사용하는 면도 있었지만, 조금이라도 더 빠른 애플리케이션을 사용하기 위해서는 moment 외에 다른 대안이 필요했다.
그러던 중, <a href="https://momentjs.com/docs/">moment 가 deprecated 된다는 소식을 알려왔다.</a>
<blockquote>
... The modern web looks much different these days. Moment has evolved somewhat over the years, but it has essentially the same design as it did when it was created in 2011. Given how many projects depend on it, we choose to prioritize stability over new features.
</blockquote>
조금 많이 뒷북이긴 하지만, 왜 moment가 역사 속으로 사라졌는지 몇가지 이유를 짚고 넘어가고자 한다.
<h2 id="1-느리다">1. 느리다</h2>
단도직입적으로 그래프를 통해서 알수 있다. 다른 datetime library 대비 속도가 많이 느렸다.
<img src="https://raygun.com/blog/wp-content/uploads/2017/09/image4-2.png" alt="speed1">
<img src="https://raygun.com/blog/wp-content/uploads/2017/09/image3.png" alt="speed2">
<img src="https://raygun.com/blog/wp-content/uploads/2017/09/image1.png" alt="speed3">
출처: <a href="https://raygun.com/blog/moment-js-vs-date-fns/">https://raygun.com/blog/moment-js-vs-date-fns/</a>
뭐 여러가지 이유가 있겠지만, regex를 주로 쓰는 moment에 대비 다른 라이브러리들은 <code>Z</code>로 끝나면 <code>new Date(string)</code>을 쓴다던지, 혹은 느린 regex 대신에 자체적으로 개발한(?) <code>if</code> 와 <code>charAt</code> 등을 쓴다던지 다양한 노력들을 하고 있었다. regex를 파싱해서 이해하는 작업은 확실히 느리다.
<h2 id="2-무겁다">2. 무겁다</h2>
<img src="./images/size-of-datetime-libraries.png" alt="size-of-datetime-libraries">
출처: <a href="https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js">https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js</a>
<a href="https://github.com/jmblog/how-to-optimize-momentjs-with-webpack">https://github.com/jmblog/how-to-optimize-momentjs-with-webpack</a>
기본적으로 momentjs는 232kb, (gzip시 66kb) 이며, webpack으로 locale을 제거할 경우 사이즈는 68kb (gzip시 23kb) 까지 떨어진다. 그리고 더이상의 tree shaking은 불가능하다. js-joda가 제법 크긴 하지만 기간과 타임존까지 기본으로 제공하는 라이브러리라는 것을 알아둬야 한다. 그리고 나머지 라이브러리들은 트리쉐이킹이 가능하다.
<h2 id="3mutable이다">3.mutable이다.</h2>
이는 moment 공식 가이드에서도 언급한 문제다.
<blockquote>
As an example, consider that Moment objects are mutable. This is a common source of complaints about Moment. We address it in our usage guidance but it still comes as a surprise to most new users. Changing Moment to be immutable would be a breaking change for every one of the projects that use it. Creating a "Moment v3" that was immutable would be a tremendous undertaking and would make Moment a different library entirely. Since this has already been accomplished in other libraries, we feel that it is more important to retain the mutable API.
</blockquote>
<a href="https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js">https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js</a>
<pre class="language-javascript"><code class="language-javascript">const startedAt = moment()
const endedAt = startedAt.add(1, 'year')

console.log(startedAt) // > 2020-02-09T13:39:07+01:00
console.log(endedAt) // > 2020-02-09T13:39:07+01:00
</code></pre>
<code>moment</code>를 조작하는 모든 method 들은 리턴 값과 참조값 모두를 바꿔 버리기 때문에, 에러를 만들 소지가 높다.
<h2 id="4-디버깅이-어렵다">4. 디버깅이 어렵다.</h2>
<code>moment</code>안에 파라미터를 넣는 것은 좋은 아이디어이긴하지만, 그 안에 따라서 동작이 매우 일관적이지 못하다. 예를 들어, moment 안에 잘못된 값을 넣었을 경우 에러가 나는게 아니라 그냥 현재 시간이 나와버릴 수도 있다.
<pre class="language-javascript"><code class="language-javascript">moment().format() // > 2019-02-08T17:07:22+01:00
moment(undefined).format() // > 2019-02-08T17:07:22+01:00
moment(null).format() // > Invalid date
moment({}).format() // > 2019-02-08T17:07:22+01:00
moment('').format() // > Invalid date
moment([]).format() // > 2019-02-08T17:07:22+01:00
moment(NaN).format() // > Invalid date
moment(0).format() // > 1970-01-01T01:00:00+01
</code></pre>
요약하자면, <code>undefined</code>는 가능하지만, <code>null</code> <code>''</code>, <code>NaN</code>은 안된다.
<h2 id="결국">결국</h2>
lighthouse에서도 에러가 뜨고
<img src="https://pbs.twimg.com/media/EhM0XE3UwAA2Co5?format=jpg&#x26;name=medium" alt="lighthouse warning">
<a href="https://twitter.com/addyosmani/status/1304676118822174721">https://twitter.com/addyosmani/status/1304676118822174721</a>
moment를 최적화 하는 방법까지도 알려지기 시작했다.
<a href="https://github.com/GoogleChromeLabs/webpack-libs-optimizations#moment">https://github.com/GoogleChromeLabs/webpack-libs-optimizations#moment</a>
<h2 id="대안">대안</h2>
사이즈가 중요한 프론트엔드의 경우 <code>date-fns</code>나 <code>day.js</code>가 좋다. 그 외의 경우에는 기능이 가장 리치한 <code>js-joda</code>를 사용하는 것이 좋다.
<table>
<thead>
<tr>
<th></th>
<th>size</th>
<th>size(gzip)</th>
<th>speed(to)</th>
<th>tree-shaking</th>
<th>immutable</th>
<th>throw error</th>
<th>timezone</th>
</tr>
</thead>
<tbody>
<tr>
<td>moment</td>
<td>232/68</td>
<td>66/26</td>
<td>16.527</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>O</td>
</tr>
<tr>
<td>day.js</td>
<td>6</td>
<td>3</td>
<td>9.129</td>
<td>X</td>
<td>O</td>
<td>X</td>
<td>X</td>
</tr>
<tr>
<td>luxon</td>
<td>64</td>
<td>18</td>
<td>15.406</td>
<td>X</td>
<td>O</td>
<td>O</td>
<td>O</td>
</tr>
<tr>
<td>js-joda</td>
<td>208</td>
<td>39</td>
<td>11.397</td>
<td>X</td>
<td>O</td>
<td>O</td>
<td>O</td>
</tr>
<tr>
<td>date-fns</td>
<td>30</td>
<td>7</td>
<td>5.175</td>
<td>O</td>
<td>O</td>
<td>X</td>
<td>X</td>
</tr>
<tr>
<td>native</td>
<td></td>
<td></td>
<td>1.297</td>
<td></td>
<td>X</td>
<td>X</td>
<td>X</td>
</tr>
</tbody>
</table>
출처: <a href="https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js#fnref2">https://inventi.studio/en/blog/why-you-shouldnt-use-moment-js#fnref2</a>
그럼에도, 저렇게 큰 라이브러리 자체를 deprecated 시킬 수 있다는 것 만으로도 자바스크립트 생태계가 건강하게 나아가고 있다는 방증인 것 같다. 여전히, 많은 수의 프로젝트가 moment에 의존하고 또 그 편리함에 많은 도움을 얻었다. moment가 이야기 한 <code>modern web looks much different these days</code> 처럼, 이제는 다른 라이브러리를 쓸 때가 왔다. 그리고 나 또한, 오래되고 낡은 코드를 과감하게 deprecated 시킬 용기가 필요하다.

가비지 컬렉션은 모든 언어에서 굉장히 중요한 프로세스다. C와 같은 언어에서 수동으로 처리하고, 다른 언어에서는 이를 자동으로 처리한다. 이를 자바스크립트 내부에서는 어떻게 처리할까?

## 자바스크립트 메모리 라이프 사이클

거의 모든 프로그래밍 언어의 메모리 라이프 사이클은 다음과 같이 작동한다.

1. allocate (할당)
2. use (사용)
3. release (해제)

차이 점은 이를 수행하는 방식 (사용하는 알고리즘)과 각 단계를 처리하는 방식(수동인지, 자동인지 여부)에 있다.

자바스크립트의 경우, 할당 및 해제는 자동으로 이루어 진다. 그렇다고 해서 개발자가 이에 대해 관심을 갖지 말라는 것은 아니다. 무한 루프, 잘못된 재귀처리, 콜백 지옥 등은 메모리 낭비를 이르켜 메모리 누수로 이어진다. 따라서 코딩을 잘해서 이러한 시나리오가 발생하지 않도록 하는 것이 중요하다.

자바스크립트의 경우, 새로운 변수가 선언되면 메모리에 공간이 할동 된다.

```javascript
var bar = 'bar'
```

그리고 메모리가 더이상 사용되지 않는다면, [변수 스코프](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var) 제한을 고려하여 메모리 공간 해제가 이루어진다.

하지만 어떻게 자바스크립트에서 더이상 메모리가 사용되지 않는다는 것을 알까? 그것은 바로 가비지 콜렉를 통해서 이루어진다.

## 가비지 콜렉션 전략

자바스크립트는 두개의 유명한 가비지 콜렉션 전략을 사용한다.

- Reference-counting
- Mark-and-sweep

[레퍼런스 카운팅](https://en.wikipedia.org/wiki/Reference_counting)은 파일, 소켓, 메모리 슬롯등 할당된 각 리소스를 가리키는 참조의 수를 계산하는 것이다.

메모리에 할당된 각 객체에 연결된 count 필드가 포함되어 있다고 생각해보자. 객체에 더이상 가리키는 참조가 없을 때 자동으로 가비지 콜렉팅 된다.

```javascript
var bar = {
  name: 'bar',
}
bar = ''
```

위 예제에서 `bar`와 `name`이 존재한다. `bar`는 새로운 값을 받았기 때문에, `name`은 가비지 콜렉팅 된다.

좀 더 복잡한 아래 예제를 살펴보자.

```javascript
var bar = {
  name: 'bar',
}
var bar = 'foo'

function check() {
  var bar = {}
  var foo = {}
  bar.name = foo
  foo.name = bar

  return true
}
check()
```

자바스크립트는 객체에 대한 참조 기반의 언어로, 이는 즉 객체 명이 매모리 내 인스턴스화 된 값을 가리키는 것을 의미한다. 이 예제에서는, 자식의 객채/변수는 부모가 자동으로 참조한다.

위 예제에서는 순환 참조를 만들고 있다. `check`함수내의 `bar`는 `foo`를 참조하고 있으며 그 반대 경우도 마찬가지다.

일반적으로 함수가 실행을 마치면 내부 요소는 가비지 컬렉팅이 된다. 그러나 이경우에는 객체가 여전히 서로 참조되고 있기 때문에 가비지 컬렉팅 되지 않는다.

여기에서 이제 자바스크립트의 두번째 작전인 `mark-and-sweep` 알고리즘이 동작한다.

이 알고리즘은 자바스크립트의 최상위 객체인 `global`(`window`)에 도달할 수 없는 객체를 찾는 방식으로 작동한다.

![mark-and-sweep1](https://d33wubrfki0l68.cloudfront.net/eff15dde3b4a6db32945c32b8b04047bc9ec9b8a/47eba/images/blog/2020-10/figure2.png)

보시다시피, 자바스크립트는 `name` 객체를 최상위에서 쉽게 찾을 수 있다.

만약 다음 코드가 실행되면 어떻게 될까?

```javascript
var bar = 'foo'
```

![mark-and-sweep2](https://d33wubrfki0l68.cloudfront.net/ad95ba131dc543352e80b6b34d48cf2003c7011b/3160a/images/blog/2020-10/figure3.png)

이제 더이상 `name`은 root에서 접근할 수 없는 객체가 된다.

나머지 프로세스는 굉장히 직관적이다. 알고리즘은 루트에서 하단의 객체까지 각각 루트에서 접근할 수 있는 객체인지, 혹은 `name`처럼 더이상 접근할 수 없는 객체인지를 별도로 표시해둔다.

이 과정은 자바스크립트의 GC만 알고 있는 몇몇 내부 조건을 통해 반복되고 있는데, 이는 대부분의 언어의 GC에서도 동일하게 동작한다.

## Node.js의 가비지 콜렉션

Node.js의 가비지 콜렉션이 어떻게 동작하는지 이해하기 전에, heap과 stack에 대해서 알아두어야 한다.

heap은 참조유형에 해당하는 데이터들이 나타나는 곳이다. 여기서 참조 유형이라 함은 객체, string, 클로져 등을 의미한다.

따라서 자바스크립트에서 객체가 만들어지면, 객체는 heap에 위치하게 된다.

```javascript
const myCat = new Cat('Joshua')
```

반면에, stack은 heap에서 생성된 객체에 대한 참조가 저장되는 곳이다. 예를 들어 함수의 argument는 stack에 존재하는 참조의 좋은 예다.

```javascript
function Cat(name) {
  this.name = name
}
```

그리고 힙은 `new space`와 `old space`로 나누어진다.

![heap](https://d33wubrfki0l68.cloudfront.net/0c2c3b1c7345423b26f87fa469dac4b20ec11d16/5db77/images/blog/2020-10/figure4.png)

`New space`는 새로운 객체와 변수를 할당하는 메모리 영역이며, 이름 그대로 새로운 것들이기 때문에 GC 처리가 빠르다. 이름에서 알 수 있듯이, 이영역은 비교적 이르게 할당된 객체들이 존재한다.

`Old space`는 `new space`에서 수집되지 않는 객체들이 얼마 후에 이동하는 곳이다. 사이즈가 큰 객체나, V8로 컴파일된 코드와 같은 것들이 존재한다.

Node.js는 GC가 `old space`로 가지 않도록 최선을 다한다. 왜냐하면 `old space`는 GC를 하는데 더 많은 비용이 들기 때문이다. 따라서 전체 대상의 20% 정도만 `old space`로 이동한다.

- `Scavenge`: 이 가비지 컬렉터는 실행될 때마다 메모리의 작은 부분을 청소하여 `young generation`을 처리한다. 매우 빠르다.
- `Mark-and-sweep`: 아까 언급했던 알고리즘으로, 느리지만 `old generation`에서 유용하게 동작할 수 있다.

## Node.js의 메모리 누수 예제

자바스크립트가 Nodejs 에서 메모리를 다루는 방법을 보는 좋은 예제는 아주 클래식한 메모리 누수 예제를 보는 것이다. 메모리 누수는 모든 GC전략이 루트 객체와의 연결을 잃어서 객체를 찾지 못할 때 발생한다. 그 외에도, 객체가 항상 다른 객체에 의해 참조되면서 동시에 크기가 커지는 경우에도 발생할 수 있다.

예를 들어 간단한 nodejs서버가 아래와 같이 있으며, 모든 요청에서 중요한 데이터를 저장하려 한다고 생각해보자.

```javascript
const http = require('http')

const ml_Var = []
const server = http.createServer((req, res) => {
  let chunk = JSON.stringify({ url: req.url, now: new Date() })
  ml_Var.push(chunk)

  res.writeHead(200)
  res.end(JSON.stringify(ml_Var))
})

const PORT = process.env.PORT || 3000
server.listen(PORT)
```

모든 요청에 대해서 json stringify로 리스트에 푸쉬한다고 가정해보자. `ml_Var`는 글로벌 변수 이기 때문에 서버가 종료될 때 까지 메모리에서 계속 존재할 수 있다. 이는 굉장히 위험한 지점이다.

특히 다른 개발자들이, 내가 볼 수 없는 지점에서 아이템을 추가할 수 있기 때문에, 이러한 객체는 애플리케이션에서 문제를 야기할 수 있다.

```bash
node --inspect index.js
```

```bash
Debugger listening on ws://127.0.0.1:9229/16ee16bb-f142-4836-b9cf-859799ce8ced
For help, see: https://nodejs.org/en/docs/inspector
```

이제 크롬에서 `chrome://inspect` 명령어로 살펴보면 아래와 같은 화면이 나온다.

![chrome-inspection](./images/chrome-inspection.png)

`remote target` 섹션에 `inspect`링크가 있다. 이를 클릭하면, nodejs 애플리케이션의 세션을 볼 수 있는 화면이 뜬다. 로그, 소스, CPU 프로파일링 및 메모리 분석 등을 수행할 수 있다.

메모리 탭에서 `Take snapshot`을 크릭하면, 현재 실행중인 애플리케이션의 더미 스냅샷 프로필 (메모리 덤프)를 생성한다. 메모리 누수가 일어나기 전후의 메모리를 비교하는 것이 일단 목표다.

메모리 덤프를 가져오기에 앞서, 벤치 마킹을 돕기 위한 도구로 [siege.js](https://www.npmjs.com/package/siege)를 사용할 것이다. 이 라이브러리는 엔드포인트에 대해 수백 수천건의 요청을 실행하는 작업을 단순화 하는 node.js의 벤치마킹 도구다.

```javascript
const siege = require('siege')
siege().on(3000).for(2000).times.get('/').attack()
```

3000포트에 대해서 `/`요청을 2000번 날릴 것이다.

```bash
GET:/
GET:/
GET:/
GET:/
GET:/GET:/GET:/GET:/        done:2000        200 OK: 2000        rps: 2721        response: 1ms(min)      24ms(max)     5ms(avg)
```

DevTool로 돌아가서 `Take snap shot`버튼을 누르자.

![siege](./images/siege.png)

수 많은 string 들이 쌓인 것을 볼 수 있다. 실제 애플리케이션이었다면, 더 많은 양의 string 이 쌓여 있을 것이다. 따라서 이러한 메모리 누수를 조기에 발견하고 해결해야 할 것이다.

## 더 읽어보기

- [ibm의 javascript memory leak 보고서](https://www.ibm.com/developerworks/web/library/wa-memleak/wa-memleak-pdf.pdf)
- [Mozilla Performance](https://developer.mozilla.org/en-US/docs/Mozilla/Performance)


원래 이런건 이해가 될 때 까지 하는거임

자바스크립트의 가비지 컬렉션

가비지 컬렉션은 모든 언어에서 굉장히 중요한 프로세스다. C와 같은 언어에서 수동으로 처리하고, 다른 언어에서는 이를 자동으로 처리한다. 이를 자바스크립트 내부에서는 어떻게 처리할까?
<h2 id="자바스크립트-메모리-라이프-사이클">자바스크립트 메모리 라이프 사이클</h2>
거의 모든 프로그래밍 언어의 메모리 라이프 사이클은 다음과 같이 작동한다.
<ol>
<li>allocate (할당)</li>
<li>use (사용)</li>
<li>release (해제)</li>
</ol>
차이 점은 이를 수행하는 방식 (사용하는 알고리즘)과 각 단계를 처리하는 방식(수동인지, 자동인지 여부)에 있다.
자바스크립트의 경우, 할당 및 해제는 자동으로 이루어 진다. 그렇다고 해서 개발자가 이에 대해 관심을 갖지 말라는 것은 아니다. 무한 루프, 잘못된 재귀처리, 콜백 지옥 등은 메모리 낭비를 이르켜 메모리 누수로 이어진다. 따라서 코딩을 잘해서 이러한 시나리오가 발생하지 않도록 하는 것이 중요하다.
자바스크립트의 경우, 새로운 변수가 선언되면 메모리에 공간이 할동 된다.
<pre class="language-javascript"><code class="language-javascript">var bar = 'bar'
</code></pre>
그리고 메모리가 더이상 사용되지 않는다면, <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var">변수 스코프</a> 제한을 고려하여 메모리 공간 해제가 이루어진다.
하지만 어떻게 자바스크립트에서 더이상 메모리가 사용되지 않는다는 것을 알까? 그것은 바로 가비지 콜렉를 통해서 이루어진다.
<h2 id="가비지-콜렉션-전략">가비지 콜렉션 전략</h2>
자바스크립트는 두개의 유명한 가비지 콜렉션 전략을 사용한다.
<ul>
<li>Reference-counting</li>
<li>Mark-and-sweep</li>
</ul>
<a href="https://en.wikipedia.org/wiki/Reference_counting">레퍼런스 카운팅</a>은 파일, 소켓, 메모리 슬롯등 할당된 각 리소스를 가리키는 참조의 수를 계산하는 것이다.
메모리에 할당된 각 객체에 연결된 count 필드가 포함되어 있다고 생각해보자. 객체에 더이상 가리키는 참조가 없을 때 자동으로 가비지 콜렉팅 된다.
<pre class="language-javascript"><code class="language-javascript">var bar = {
 name: 'bar',
}
bar = ''
</code></pre>
위 예제에서 <code>bar</code>와 <code>name</code>이 존재한다. <code>bar</code>는 새로운 값을 받았기 때문에, <code>name</code>은 가비지 콜렉팅 된다.
좀 더 복잡한 아래 예제를 살펴보자.
<pre class="language-javascript"><code class="language-javascript">var bar = {
 name: 'bar',
}
var bar = 'foo'

function check() {
 var bar = {}
 var foo = {}
 bar.name = foo
 foo.name = bar

 return true
}
check()
</code></pre>
자바스크립트는 객체에 대한 참조 기반의 언어로, 이는 즉 객체 명이 매모리 내 인스턴스화 된 값을 가리키는 것을 의미한다. 이 예제에서는, 자식의 객채/변수는 부모가 자동으로 참조한다.
위 예제에서는 순환 참조를 만들고 있다. <code>check</code>함수내의 <code>bar</code>는 <code>foo</code>를 참조하고 있으며 그 반대 경우도 마찬가지다.
일반적으로 함수가 실행을 마치면 내부 요소는 가비지 컬렉팅이 된다. 그러나 이경우에는 객체가 여전히 서로 참조되고 있기 때문에 가비지 컬렉팅 되지 않는다.
여기에서 이제 자바스크립트의 두번째 작전인 <code>mark-and-sweep</code> 알고리즘이 동작한다.
이 알고리즘은 자바스크립트의 최상위 객체인 <code>global</code>(<code>window</code>)에 도달할 수 없는 객체를 찾는 방식으로 작동한다.
<img src="https://d33wubrfki0l68.cloudfront.net/eff15dde3b4a6db32945c32b8b04047bc9ec9b8a/47eba/images/blog/2020-10/figure2.png" alt="mark-and-sweep1">
보시다시피, 자바스크립트는 <code>name</code> 객체를 최상위에서 쉽게 찾을 수 있다.
만약 다음 코드가 실행되면 어떻게 될까?
<pre class="language-javascript"><code class="language-javascript">var bar = 'foo'
</code></pre>
<img src="https://d33wubrfki0l68.cloudfront.net/ad95ba131dc543352e80b6b34d48cf2003c7011b/3160a/images/blog/2020-10/figure3.png" alt="mark-and-sweep2">
이제 더이상 <code>name</code>은 root에서 접근할 수 없는 객체가 된다.
나머지 프로세스는 굉장히 직관적이다. 알고리즘은 루트에서 하단의 객체까지 각각 루트에서 접근할 수 있는 객체인지, 혹은 <code>name</code>처럼 더이상 접근할 수 없는 객체인지를 별도로 표시해둔다.
이 과정은 자바스크립트의 GC만 알고 있는 몇몇 내부 조건을 통해 반복되고 있는데, 이는 대부분의 언어의 GC에서도 동일하게 동작한다.
<h2 id="nodejs의-가비지-콜렉션">Node.js의 가비지 콜렉션</h2>
Node.js의 가비지 콜렉션이 어떻게 동작하는지 이해하기 전에, heap과 stack에 대해서 알아두어야 한다.
heap은 참조유형에 해당하는 데이터들이 나타나는 곳이다. 여기서 참조 유형이라 함은 객체, string, 클로져 등을 의미한다.
따라서 자바스크립트에서 객체가 만들어지면, 객체는 heap에 위치하게 된다.
<pre class="language-javascript"><code class="language-javascript">const myCat = new Cat('Joshua')
</code></pre>
반면에, stack은 heap에서 생성된 객체에 대한 참조가 저장되는 곳이다. 예를 들어 함수의 argument는 stack에 존재하는 참조의 좋은 예다.
<pre class="language-javascript"><code class="language-javascript">function Cat(name) {
 this.name = name
}
</code></pre>
그리고 힙은 <code>new space</code>와 <code>old space</code>로 나누어진다.
<img src="https://d33wubrfki0l68.cloudfront.net/0c2c3b1c7345423b26f87fa469dac4b20ec11d16/5db77/images/blog/2020-10/figure4.png" alt="heap">
<code>New space</code>는 새로운 객체와 변수를 할당하는 메모리 영역이며, 이름 그대로 새로운 것들이기 때문에 GC 처리가 빠르다. 이름에서 알 수 있듯이, 이영역은 비교적 이르게 할당된 객체들이 존재한다.
<code>Old space</code>는 <code>new space</code>에서 수집되지 않는 객체들이 얼마 후에 이동하는 곳이다. 사이즈가 큰 객체나, V8로 컴파일된 코드와 같은 것들이 존재한다.
Node.js는 GC가 <code>old space</code>로 가지 않도록 최선을 다한다. 왜냐하면 <code>old space</code>는 GC를 하는데 더 많은 비용이 들기 때문이다. 따라서 전체 대상의 20% 정도만 <code>old space</code>로 이동한다.
<ul>
<li><code>Scavenge</code>: 이 가비지 컬렉터는 실행될 때마다 메모리의 작은 부분을 청소하여 <code>young generation</code>을 처리한다. 매우 빠르다.</li>
<li><code>Mark-and-sweep</code>: 아까 언급했던 알고리즘으로, 느리지만 <code>old generation</code>에서 유용하게 동작할 수 있다.</li>
</ul>
<h2 id="nodejs의-메모리-누수-예제">Node.js의 메모리 누수 예제</h2>
자바스크립트가 Nodejs 에서 메모리를 다루는 방법을 보는 좋은 예제는 아주 클래식한 메모리 누수 예제를 보는 것이다. 메모리 누수는 모든 GC전략이 루트 객체와의 연결을 잃어서 객체를 찾지 못할 때 발생한다. 그 외에도, 객체가 항상 다른 객체에 의해 참조되면서 동시에 크기가 커지는 경우에도 발생할 수 있다.
예를 들어 간단한 nodejs서버가 아래와 같이 있으며, 모든 요청에서 중요한 데이터를 저장하려 한다고 생각해보자.
<pre class="language-javascript"><code class="language-javascript">const http = require('http')

const ml_Var = []
const server = http.createServer((req, res) => {
 let chunk = JSON.stringify({ url: req.url, now: new Date() })
 ml_Var.push(chunk)

 res.writeHead(200)
 res.end(JSON.stringify(ml_Var))
})

const PORT = process.env.PORT || 3000
server.listen(PORT)
</code></pre>
모든 요청에 대해서 json stringify로 리스트에 푸쉬한다고 가정해보자. <code>ml_Var</code>는 글로벌 변수 이기 때문에 서버가 종료될 때 까지 메모리에서 계속 존재할 수 있다. 이는 굉장히 위험한 지점이다.
특히 다른 개발자들이, 내가 볼 수 없는 지점에서 아이템을 추가할 수 있기 때문에, 이러한 객체는 애플리케이션에서 문제를 야기할 수 있다.
<pre class="language-bash"><code class="language-bash">node --inspect index.js
</code></pre>
<pre class="language-bash"><code class="language-bash">Debugger listening on ws://127.0.0.1:9229/16ee16bb-f142-4836-b9cf-859799ce8ced
For help, see: https://nodejs.org/en/docs/inspector
</code></pre>
이제 크롬에서 <code>chrome://inspect</code> 명령어로 살펴보면 아래와 같은 화면이 나온다.
<img src="./images/chrome-inspection.png" alt="chrome-inspection">
<code>remote target</code> 섹션에 <code>inspect</code>링크가 있다. 이를 클릭하면, nodejs 애플리케이션의 세션을 볼 수 있는 화면이 뜬다. 로그, 소스, CPU 프로파일링 및 메모리 분석 등을 수행할 수 있다.
메모리 탭에서 <code>Take snapshot</code>을 크릭하면, 현재 실행중인 애플리케이션의 더미 스냅샷 프로필 (메모리 덤프)를 생성한다. 메모리 누수가 일어나기 전후의 메모리를 비교하는 것이 일단 목표다.
메모리 덤프를 가져오기에 앞서, 벤치 마킹을 돕기 위한 도구로 <a href="https://www.npmjs.com/package/siege">siege.js</a>를 사용할 것이다. 이 라이브러리는 엔드포인트에 대해 수백 수천건의 요청을 실행하는 작업을 단순화 하는 node.js의 벤치마킹 도구다.
<pre class="language-javascript"><code class="language-javascript">const siege = require('siege')
siege().on(3000).for(2000).times.get('/').attack()
</code></pre>
3000포트에 대해서 <code>/</code>요청을 2000번 날릴 것이다.
<pre class="language-bash"><code class="language-bash">GET:/
GET:/
GET:/
GET:/
GET:/GET:/GET:/GET:/ done:2000 200 OK: 2000 rps: 2721 response: 1ms(min) 24ms(max) 5ms(avg)
</code></pre>
DevTool로 돌아가서 <code>Take snap shot</code>버튼을 누르자.
<img src="./images/siege.png" alt="siege">
수 많은 string 들이 쌓인 것을 볼 수 있다. 실제 애플리케이션이었다면, 더 많은 양의 string 이 쌓여 있을 것이다. 따라서 이러한 메모리 누수를 조기에 발견하고 해결해야 할 것이다.
<h2 id="더-읽어보기">더 읽어보기</h2>
<ul>
<li><a href="https://www.ibm.com/developerworks/web/library/wa-memleak/wa-memleak-pdf.pdf">ibm의 javascript memory leak 보고서</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Performance">Mozilla Performance</a></li>
</ul>

대부분의 프론트엔드 개발자들은 V8이라는 용어를 들어본 적이 있을 것이다. V8은 구글에서 만든 오픈소스 자바스크립트 및 웹 어셈블리 엔진으로, C++ 로 작성 되어있으며 현재 크롬과 Nodejs 등에서 사용되고 있다. V8의 중요한 역할 중 하나는 generational (데이터의 시간에 따라서 정렬한다는 뜻인데, 정확히 뭐라고 표현해야 할지 모르겠다) 하면서도 매우 정확한 가비지 콜렉션이다. 메모리를 많이 사용하지 않더라도, 자바스크립트가 더 이상 필요하지 않은 객체를 수집하도록 최적화 되어 있다. 이 외에도 V8은 역사적으로 자바스크립트의 속도를 느리게 만드는 고유의 기능성을 개선하기 위해 일련의 다른 툴과 feature들을 사용한다. 이 글에서 이러한 도구 (Ignition 과 TurboFan)와 다양한 기능에 대해서 알아보고자 한다. 그 외에도 V8의 내부 기능, 컴파일 및 가비지 콜렉션 절차, 단일 스레드 특성 등의 기본 특성을 알아보고자 한다. 기회가 된다면, 정말 V8을 코드 레벨로도 살펴볼 수 있었으면 좋겠다.

## 기초부터 살펴보기

기계 코드 (Machine code)는 어떻게 동작할까? 기계 코드란 메모리의 특정부분에서 실행될 수 있는 매우 저수준의 언어 명령의 집합이다. C++ 를 기준으로 그 과정을 묘사해보자면 아래와 같다.

![process](https://d33wubrfki0l68.cloudfront.net/b08f7bc5a007ad810a62c6c2edf1510bcd18001f/2f357/images/blog/2020-07/figure01.png)

더 나아가기전에, 자바스크립트의 interpretation 과 는 다른 컴파일 과정이라는 것에 대해 알아볼 필요가 있다. 컴파일러는 프로세스가 끝날 때 전체 프로그램을 생성하는 반면, interpreter는 instruction (자바스크립트의 스크립트와 같은)을 읽고 실행 가능한 명령으로 말 그대로 번역하여 그 일을 하는 프로그램으로 자체 동작하게 된다.

이러한 interpretation 과정은 즉시 (인터프리터가 현재 명령 구문만 분석하고 실행) 이루어지거나 완전히 구문 분석을 마친뒤에 (인터프리터가 기계명령을 진행하기 전에 스크립트 전체를 완전히 번역할때) 모두 발생할 수 있다.

그림으로 돌아가서 다시 보면, 컴파일 프로세스는 일반적으로 알려져 있는 것처럼 소스코드로부터 시작된다. 코드를 구현하고, 이를 저장한 뒤에 실행한다. 컴파일러는 여느 프로그램처럼 머신에서 실행된다. 그런 다음 모든 코드를 살펴보고 객체 파일을 생성한다. 이러한 파일은 기계 코드다. 특정 컴퓨터에서 실행되는 최적화된 코드이므로 다른 OS 에서 이를 활용 할 때는 다른 컴파일러를 사용해야 한다.

그러나 이를 위해 별도의 객체 파일을 실행할 수는 없으므로, `.exe`와 같이 실행파일 형태의 단일 파일로 결합해야 한다. 이것이 바로 링커의 일이다.

마지막으로 로더는 해당 exe 파일의 코드를 OS 의 가상메모리로 전송하는 에이전트 이다. 그리고 마침내 프로그램이 실행된다.

대부분의 경우 (은행의 메인 프레임에서 Assembly로 직접 작업하는 개발자가 아니라면) Java, C#, Ruby, Javascript 와 같은 고수준 언어로 프로그래밍을 하는데 많은 시간을 할애 한다. 언어의 수준은 높을 수록 느리다. 기계어 코드인 어셈블리언어에 가까울 수록 빨라지며, 그렇기 때문에 C와 C++이 빠르다.

성능과 별도로 V8의 주요 이점 중 하나는 ECMAScript 표준을 넘어서 C++ 도 이해 할 수 있다는 것이다.

![V8](https://d33wubrfki0l68.cloudfront.net/d056b38131c76fa5337d0fc172b70382662d87e6/8f55e/images/blog/2020-07/figure02.png)

자바스크립트의 기능은 ECMAScript를 준수한다. 그리고 V8은 이 규정을 준수하는 한편으로, 이에 제한되지 않는다.

C++ 기능을 V8에 이용할 수 있는 능력은 매우 훌륭하다. C++은 파일조작, 메모리 및 스레드 처리와 같은 OS의 특수성을 매우 능숙하게 다를 수 있는데, 이러한 기능을 자바스크립트에서도 할 수 있게 끔 구현 해 두었다.

## 단일 스레드

Node 개발자라면 V8의 단일 스레드 특성에 익숙할 것이다. 각 자바스크립트 실행 컨텍스트는 하나의 스레드를 가지고 있다. 물론 이러한 OS 쓰레드 메커니즘을 V8이 뒤에서 제어하고 있다. 복잡한 소프트웨어이고, 동시에 많은 것을 수행해야 하기 때문에 이는 둘 이상의 스레드에서 작동한다. 코드를 실행하는 메인스레드, 코드를 컴파일를 다른 스레드, 가비지를 수집하는 스레드 등이 존재할 수 있다.

그러나 V8은 각 자바스크립트 컨텍스트 마다 하나의 싱글 스레드 환경을 만들어준다. 나머지는 V8의 제어 하에 놓여져 있다.

자바스크립트 코드가 호출한 함수의 스택을 상상해보자. 자바스크립트는 각 함수를 삽입 또는 호출한 순서에 따라 한 함수를 다른 함수 위에 쌓는 (스택) 방식으로 작동한다. 각 함수의 콘텐츠에 도달하기 전까지, 다른 함수를 호출하는지를 알 수 없다. 만약 그렇게 된다면, 호출자의 바로 뒤에 호출된 함수가 스택으로 배치될 것이다. 예를 들어 콜백의 경우, 맨 끝에 놓여지게 된다.

이러한 스택의 관리와 메모리 배치가 V8의 메인 작업 중 하나다.

## Ignition, Turbofan

2017년 5월에 발표된 5.9 버전 이후로, V8은 [Ignition](https://v8.dev/docs/ignition) 이라고 하는 V8 인터프리터를 자바스크립트 실행 파이프라인 최 상단에 배치 하였다. 또한 더 나은 최적화 컴파일러인 [Turbofan](https://v8.dev/docs/turbofan)도 모습을 드러냈다.

이러한 변화는 전체적인 성능에 초점을 맞추었고, 구글 개발자들이 자바스크립트 생태계가 제기하는 빠르고 상당한 엔진의 변화를 적용할 때 구글 개발자들이 직면하는 어려움을 해결하는데 중점을 두었다. 프로젝트가 시작될 때 부터 V8 메인테이너들은 자바스크립트가 진화하는 것과 같은 속도로 V8의 성능을 향상 시킬 수 있는 좋은 방법을 찾는것에 대한 고민이 있었다. 이러한 노력 덕분에, 새엔진을 가동할 때 큰 성능의 이점을 볼 수 있다.

![performance-of-5.9](https://d33wubrfki0l68.cloudfront.net/c145cd3d5a9719cb841c61baf13fef7819b41450/c4b00/images/blog/2020-07/figure03.png)

## Hidden Classes

V8의 마법같은 요소 중 하나다. 자바스크립트는 동적 언어다. 즉 실행 되는 과정에서 새로운 속성이 추가되거나, 대체되거나, 삭제될 수 있다는 것을 의미한다. 자바나 대다수의 언어의 경우 애플리케이션 시작 이후에는 동적으로 변경될 수 없는 언어와는 다른 차이다. 이러한 특징 때문에 해시 함수를 기초로한 dictionary lookup을 수행하여 이 변수가 객체가 메모리에 할당되는 위치를 장확히 알고 있다. 그러나 이는 최종 프로세스에 많은 비용이 든다. 이에 반해 다른언어에서는 객체가 생성될 때, 암묵적인 속성 중 하나로 주소(포인터)를 받는다. 이 방법으로 이들이 메모리 어디에 위치하고 있는지, 얼마나 많은 공간을 할당해야 하는지를 정확히 알 소 있다.

그러나 자바스크립트는 아직 존재하지 않는 것을 매핑할 수 없기 때문에 이러한 방법을 적용하는 것은 불가능하다. 그리고 여기에서 hidden class를 사용한다. 이는 자바에서와 거의 동일하다. 고정된 클래스와 고유 주소를 사용하여 위치를 찾는다. 그러나 프로그램 실행전에 하는 것이 아니고, V8은 런타임 도중에, 객체의 구조에 동적인 변화가 수행될 때 마다 이를 수행한다. 아래 코드를 살펴보자.

```javascript
function User(name, phone, address) {
  this.name = name
  this.phone = phone
  this.address = address
}
```

자바스크립트는 프로토타입 기반의 언어이므로, User 객체를 초기화 하면 아래처럼 된다.

```javascript
var user = new User('John May', '+1 (555) 555-1234', '123 3rd Ave')
```

그러면 V8은 hidden class를 만든다. `_User0`이라고가정하자.

![_User0](https://d33wubrfki0l68.cloudfront.net/a875a24a8469140ca028f18f67a9b2c3f46cdef3/51e3d/images/blog/2020-07/figure04.png)

각 객체는 메모리에서 클래스 표현에 대한 참조를 가지고 있다. 이 시점에서 방금 새로운 객체를 인스턴스화 했기 때문에, 메모리 속에 숨겨진 클래스를 만들었다. 그리고 당장은 비어있다. 그리고 함수의 첫번째 줄을 실행하게 되면, 새로운 hidden class가 이전 hidden class를 기반으로 생성된다. 그리고 이를 `_User1`이라고 해보자.

![_User1](https://d33wubrfki0l68.cloudfront.net/af62dca2334af839e484b038be90d54bb3119a22/ccce1/images/blog/2020-07/figure05.png)

기본적으로 `User`의 메모리 주소는 `name`속성을 갖는다. 이 예제에서는, `name`만 가진 `user`를 속성으로 사용하는 것이 아니라, 매번 이렇게 할 때마다 hidden class V8이 참조로 로드된다. `name` 속성은 메모리 버퍼에 `offset 0`으로 추가되는데, 이 뜻은 첫번째 속성으로 분류된다는 것이다.

V8은 또항 transition value를 `_User0` hidden class에 추가 했다. 이는 인터프리터가 `User`에 `name`속성이 추가 될 때 마다, `_User0`에서 `_User1` 로 값의 이동이 이루어 져야 한다는 것을 알려 준다.

그리고 두번째 줄이 호출되면, 같은 과정이 반복되면서 hidden class 가 생성된다.

![_User2](https://d33wubrfki0l68.cloudfront.net/1ab5bbae18ab7ed6fccc301c742ba15dd9599503/57581/images/blog/2020-07/figure06.png)

hidden class가 스택형태로 쌓여 있는 것을 볼 수 있다. 하나의 hidden class가 체이닝 형태로 값을 이어가고 있는 것을 볼 수 있다. 이 속성의 순서는 V8이 hidden class를 만드는 순서를 결정한다. 속성의 순서를 바꾼다면, 생성되는 hidden class의 순서도 바뀐다. 이러한 이유 때문에 개발자들이 가급적이면 존재하는 hidden class를 재사용하기 위해 속성의 순서를 유지하는 것이다.

## 인라인 캐싱

JIT 컴파일러를 사용한다면 이는 매우 익숙한 용어다. 이는 hidden class의 콘셉트와 바로 직결된다. 예를 들어, 객체를 매개변수로 하는 함수를 호출 할 때마다 V8은 이 동작을 보고, "음.. 이 객체는 이 함수에 대한 매개변수를 두번이상 성공적으로 전달했군, hidden class를 검증하는 프로세스를 다시 수행하지 않고 향후 호출을 위해 캐시에 저장해두면 어떨까?" 라는 생각을 하게 된다.

```javascript
function User(name, fone, address) {
  // Hidden class _User0
  this.name = name // Hidden class _User1
  this.phone = phone // Hidden class _User2
  this.address = address // Hidden class _User3
}
```

`User` 객체가 함수의 파라미터로 두번이상 초기화 된다면, V8은 hidden class를 참고하는 것을 스킵하고 바로 속성의 offset을 참고한다. 이게 훨씬 빠르다. 그러나 항상 명심해 두어야 할 것은, 속성의 순서가 변하게 된다면 다른 hidden class를 만들게 되기 때문에 인라인 캐싱이 어려워진다.

## 가비지 컬렉팅

V8의 가비지 컬렉팅은 프로그램 실행 스레드와 다른 스레드에서 이뤄지기 때문에, 프로그램 실행에 영향을 미치지 않는다. V8은 [mark-and-sweep](https://en.wikipedia.org/wiki/Tracing_garbage_collection#Copying_vs._mark-and-sweep_vs._mark-and-don't-sweep)이라는 방식으로 메모리에서 죽거나 오래된 객체를 가비지 컬렉팅 한다. 이 방법은, GC가 메모리 객체를 스캔하여 수집을 위해 '표시'하는 단계는 이를 작업하기 위해 실행을 일시 중지 시키기 때문에 다소 느리다.

그러나 V8은 점진적으로 최대한 많은 객체에 'mark'를 해두려고 한다. 수집이 끝날 때 까지, 전체 실행은 중단될 필요가 없기 때문에 빠르게 이뤄진다. 대용량 애플리케이션에서는, 이러한 성능의 향상이 많은 차이를 만든다.


맛만 볼게 아니고 직접 코드 까봐서 공부를 해봐야 되는데 😭

V8 엔진에 대해 가볍게 살펴보기

대부분의 프론트엔드 개발자들은 V8이라는 용어를 들어본 적이 있을 것이다. V8은 구글에서 만든 오픈소스 자바스크립트 및 웹 어셈블리 엔진으로, C++ 로 작성 되어있으며 현재 크롬과 Nodejs 등에서 사용되고 있다. V8의 중요한 역할 중 하나는 generational (데이터의 시간에 따라서 정렬한다는 뜻인데, 정확히 뭐라고 표현해야 할지 모르겠다) 하면서도 매우 정확한 가비지 콜렉션이다. 메모리를 많이 사용하지 않더라도, 자바스크립트가 더 이상 필요하지 않은 객체를 수집하도록 최적화 되어 있다. 이 외에도 V8은 역사적으로 자바스크립트의 속도를 느리게 만드는 고유의 기능성을 개선하기 위해 일련의 다른 툴과 feature들을 사용한다. 이 글에서 이러한 도구 (Ignition 과 TurboFan)와 다양한 기능에 대해서 알아보고자 한다. 그 외에도 V8의 내부 기능, 컴파일 및 가비지 콜렉션 절차, 단일 스레드 특성 등의 기본 특성을 알아보고자 한다. 기회가 된다면, 정말 V8을 코드 레벨로도 살펴볼 수 있었으면 좋겠다.
<h2 id="기초부터-살펴보기">기초부터 살펴보기</h2>
기계 코드 (Machine code)는 어떻게 동작할까? 기계 코드란 메모리의 특정부분에서 실행될 수 있는 매우 저수준의 언어 명령의 집합이다. C++ 를 기준으로 그 과정을 묘사해보자면 아래와 같다.
<img src="https://d33wubrfki0l68.cloudfront.net/b08f7bc5a007ad810a62c6c2edf1510bcd18001f/2f357/images/blog/2020-07/figure01.png" alt="process">
더 나아가기전에, 자바스크립트의 interpretation 과 는 다른 컴파일 과정이라는 것에 대해 알아볼 필요가 있다. 컴파일러는 프로세스가 끝날 때 전체 프로그램을 생성하는 반면, interpreter는 instruction (자바스크립트의 스크립트와 같은)을 읽고 실행 가능한 명령으로 말 그대로 번역하여 그 일을 하는 프로그램으로 자체 동작하게 된다.
이러한 interpretation 과정은 즉시 (인터프리터가 현재 명령 구문만 분석하고 실행) 이루어지거나 완전히 구문 분석을 마친뒤에 (인터프리터가 기계명령을 진행하기 전에 스크립트 전체를 완전히 번역할때) 모두 발생할 수 있다.
그림으로 돌아가서 다시 보면, 컴파일 프로세스는 일반적으로 알려져 있는 것처럼 소스코드로부터 시작된다. 코드를 구현하고, 이를 저장한 뒤에 실행한다. 컴파일러는 여느 프로그램처럼 머신에서 실행된다. 그런 다음 모든 코드를 살펴보고 객체 파일을 생성한다. 이러한 파일은 기계 코드다. 특정 컴퓨터에서 실행되는 최적화된 코드이므로 다른 OS 에서 이를 활용 할 때는 다른 컴파일러를 사용해야 한다.
그러나 이를 위해 별도의 객체 파일을 실행할 수는 없으므로, <code>.exe</code>와 같이 실행파일 형태의 단일 파일로 결합해야 한다. 이것이 바로 링커의 일이다.
마지막으로 로더는 해당 exe 파일의 코드를 OS 의 가상메모리로 전송하는 에이전트 이다. 그리고 마침내 프로그램이 실행된다.
대부분의 경우 (은행의 메인 프레임에서 Assembly로 직접 작업하는 개발자가 아니라면) Java, C#, Ruby, Javascript 와 같은 고수준 언어로 프로그래밍을 하는데 많은 시간을 할애 한다. 언어의 수준은 높을 수록 느리다. 기계어 코드인 어셈블리언어에 가까울 수록 빨라지며, 그렇기 때문에 C와 C++이 빠르다.
성능과 별도로 V8의 주요 이점 중 하나는 ECMAScript 표준을 넘어서 C++ 도 이해 할 수 있다는 것이다.
<img src="https://d33wubrfki0l68.cloudfront.net/d056b38131c76fa5337d0fc172b70382662d87e6/8f55e/images/blog/2020-07/figure02.png" alt="V8">
자바스크립트의 기능은 ECMAScript를 준수한다. 그리고 V8은 이 규정을 준수하는 한편으로, 이에 제한되지 않는다.
C++ 기능을 V8에 이용할 수 있는 능력은 매우 훌륭하다. C++은 파일조작, 메모리 및 스레드 처리와 같은 OS의 특수성을 매우 능숙하게 다를 수 있는데, 이러한 기능을 자바스크립트에서도 할 수 있게 끔 구현 해 두었다.
<h2 id="단일-스레드">단일 스레드</h2>
Node 개발자라면 V8의 단일 스레드 특성에 익숙할 것이다. 각 자바스크립트 실행 컨텍스트는 하나의 스레드를 가지고 있다. 물론 이러한 OS 쓰레드 메커니즘을 V8이 뒤에서 제어하고 있다. 복잡한 소프트웨어이고, 동시에 많은 것을 수행해야 하기 때문에 이는 둘 이상의 스레드에서 작동한다. 코드를 실행하는 메인스레드, 코드를 컴파일를 다른 스레드, 가비지를 수집하는 스레드 등이 존재할 수 있다.
그러나 V8은 각 자바스크립트 컨텍스트 마다 하나의 싱글 스레드 환경을 만들어준다. 나머지는 V8의 제어 하에 놓여져 있다.
자바스크립트 코드가 호출한 함수의 스택을 상상해보자. 자바스크립트는 각 함수를 삽입 또는 호출한 순서에 따라 한 함수를 다른 함수 위에 쌓는 (스택) 방식으로 작동한다. 각 함수의 콘텐츠에 도달하기 전까지, 다른 함수를 호출하는지를 알 수 없다. 만약 그렇게 된다면, 호출자의 바로 뒤에 호출된 함수가 스택으로 배치될 것이다. 예를 들어 콜백의 경우, 맨 끝에 놓여지게 된다.
이러한 스택의 관리와 메모리 배치가 V8의 메인 작업 중 하나다.
<h2 id="ignition-turbofan">Ignition, Turbofan</h2>
2017년 5월에 발표된 5.9 버전 이후로, V8은 <a href="https://v8.dev/docs/ignition">Ignition</a> 이라고 하는 V8 인터프리터를 자바스크립트 실행 파이프라인 최 상단에 배치 하였다. 또한 더 나은 최적화 컴파일러인 <a href="https://v8.dev/docs/turbofan">Turbofan</a>도 모습을 드러냈다.
이러한 변화는 전체적인 성능에 초점을 맞추었고, 구글 개발자들이 자바스크립트 생태계가 제기하는 빠르고 상당한 엔진의 변화를 적용할 때 구글 개발자들이 직면하는 어려움을 해결하는데 중점을 두었다. 프로젝트가 시작될 때 부터 V8 메인테이너들은 자바스크립트가 진화하는 것과 같은 속도로 V8의 성능을 향상 시킬 수 있는 좋은 방법을 찾는것에 대한 고민이 있었다. 이러한 노력 덕분에, 새엔진을 가동할 때 큰 성능의 이점을 볼 수 있다.
<img src="https://d33wubrfki0l68.cloudfront.net/c145cd3d5a9719cb841c61baf13fef7819b41450/c4b00/images/blog/2020-07/figure03.png" alt="performance-of-5.9">
<h2 id="hidden-classes">Hidden Classes</h2>
V8의 마법같은 요소 중 하나다. 자바스크립트는 동적 언어다. 즉 실행 되는 과정에서 새로운 속성이 추가되거나, 대체되거나, 삭제될 수 있다는 것을 의미한다. 자바나 대다수의 언어의 경우 애플리케이션 시작 이후에는 동적으로 변경될 수 없는 언어와는 다른 차이다. 이러한 특징 때문에 해시 함수를 기초로한 dictionary lookup을 수행하여 이 변수가 객체가 메모리에 할당되는 위치를 장확히 알고 있다. 그러나 이는 최종 프로세스에 많은 비용이 든다. 이에 반해 다른언어에서는 객체가 생성될 때, 암묵적인 속성 중 하나로 주소(포인터)를 받는다. 이 방법으로 이들이 메모리 어디에 위치하고 있는지, 얼마나 많은 공간을 할당해야 하는지를 정확히 알 소 있다.
그러나 자바스크립트는 아직 존재하지 않는 것을 매핑할 수 없기 때문에 이러한 방법을 적용하는 것은 불가능하다. 그리고 여기에서 hidden class를 사용한다. 이는 자바에서와 거의 동일하다. 고정된 클래스와 고유 주소를 사용하여 위치를 찾는다. 그러나 프로그램 실행전에 하는 것이 아니고, V8은 런타임 도중에, 객체의 구조에 동적인 변화가 수행될 때 마다 이를 수행한다. 아래 코드를 살펴보자.
<pre class="language-javascript"><code class="language-javascript">function User(name, phone, address) {
 this.name = name
 this.phone = phone
 this.address = address
}
</code></pre>
자바스크립트는 프로토타입 기반의 언어이므로, User 객체를 초기화 하면 아래처럼 된다.
<pre class="language-javascript"><code class="language-javascript">var user = new User('John May', '+1 (555) 555-1234', '123 3rd Ave')
</code></pre>
그러면 V8은 hidden class를 만든다. <code>_User0</code>이라고가정하자.
<img src="https://d33wubrfki0l68.cloudfront.net/a875a24a8469140ca028f18f67a9b2c3f46cdef3/51e3d/images/blog/2020-07/figure04.png" alt="_User0">
각 객체는 메모리에서 클래스 표현에 대한 참조를 가지고 있다. 이 시점에서 방금 새로운 객체를 인스턴스화 했기 때문에, 메모리 속에 숨겨진 클래스를 만들었다. 그리고 당장은 비어있다. 그리고 함수의 첫번째 줄을 실행하게 되면, 새로운 hidden class가 이전 hidden class를 기반으로 생성된다. 그리고 이를 <code>_User1</code>이라고 해보자.
<img src="https://d33wubrfki0l68.cloudfront.net/af62dca2334af839e484b038be90d54bb3119a22/ccce1/images/blog/2020-07/figure05.png" alt="_User1">
기본적으로 <code>User</code>의 메모리 주소는 <code>name</code>속성을 갖는다. 이 예제에서는, <code>name</code>만 가진 <code>user</code>를 속성으로 사용하는 것이 아니라, 매번 이렇게 할 때마다 hidden class V8이 참조로 로드된다. <code>name</code> 속성은 메모리 버퍼에 <code>offset 0</code>으로 추가되는데, 이 뜻은 첫번째 속성으로 분류된다는 것이다.
V8은 또항 transition value를 <code>_User0</code> hidden class에 추가 했다. 이는 인터프리터가 <code>User</code>에 <code>name</code>속성이 추가 될 때 마다, <code>_User0</code>에서 <code>_User1</code> 로 값의 이동이 이루어 져야 한다는 것을 알려 준다.
그리고 두번째 줄이 호출되면, 같은 과정이 반복되면서 hidden class 가 생성된다.
<img src="https://d33wubrfki0l68.cloudfront.net/1ab5bbae18ab7ed6fccc301c742ba15dd9599503/57581/images/blog/2020-07/figure06.png" alt="_User2">
hidden class가 스택형태로 쌓여 있는 것을 볼 수 있다. 하나의 hidden class가 체이닝 형태로 값을 이어가고 있는 것을 볼 수 있다. 이 속성의 순서는 V8이 hidden class를 만드는 순서를 결정한다. 속성의 순서를 바꾼다면, 생성되는 hidden class의 순서도 바뀐다. 이러한 이유 때문에 개발자들이 가급적이면 존재하는 hidden class를 재사용하기 위해 속성의 순서를 유지하는 것이다.
<h2 id="인라인-캐싱">인라인 캐싱</h2>
JIT 컴파일러를 사용한다면 이는 매우 익숙한 용어다. 이는 hidden class의 콘셉트와 바로 직결된다. 예를 들어, 객체를 매개변수로 하는 함수를 호출 할 때마다 V8은 이 동작을 보고, "음.. 이 객체는 이 함수에 대한 매개변수를 두번이상 성공적으로 전달했군, hidden class를 검증하는 프로세스를 다시 수행하지 않고 향후 호출을 위해 캐시에 저장해두면 어떨까?" 라는 생각을 하게 된다.
<pre class="language-javascript"><code class="language-javascript">function User(name, fone, address) {
 // Hidden class _User0
 this.name = name // Hidden class _User1
 this.phone = phone // Hidden class _User2
 this.address = address // Hidden class _User3
}
</code></pre>
<code>User</code> 객체가 함수의 파라미터로 두번이상 초기화 된다면, V8은 hidden class를 참고하는 것을 스킵하고 바로 속성의 offset을 참고한다. 이게 훨씬 빠르다. 그러나 항상 명심해 두어야 할 것은, 속성의 순서가 변하게 된다면 다른 hidden class를 만들게 되기 때문에 인라인 캐싱이 어려워진다.
<h2 id="가비지-컬렉팅">가비지 컬렉팅</h2>
V8의 가비지 컬렉팅은 프로그램 실행 스레드와 다른 스레드에서 이뤄지기 때문에, 프로그램 실행에 영향을 미치지 않는다. V8은 <a href="https://en.wikipedia.org/wiki/Tracing_garbage_collection#Copying_vs._mark-and-sweep_vs._mark-and-don&#x27;t-sweep">mark-and-sweep</a>이라는 방식으로 메모리에서 죽거나 오래된 객체를 가비지 컬렉팅 한다. 이 방법은, GC가 메모리 객체를 스캔하여 수집을 위해 '표시'하는 단계는 이를 작업하기 위해 실행을 일시 중지 시키기 때문에 다소 느리다.
그러나 V8은 점진적으로 최대한 많은 객체에 'mark'를 해두려고 한다. 수집이 끝날 때 까지, 전체 실행은 중단될 필요가 없기 때문에 빠르게 이뤄진다. 대용량 애플리케이션에서는, 이러한 성능의 향상이 많은 차이를 만든다.