# 2024년 6월 4일 작업일지

### 터보팩 `RcStr` 최적화

* [**https://github.com/vercel/turbo/pull/8221**](https://github.com/vercel/turbo/pull/8221)
    
* [**https://github.com/vercel/next.js/pull/66262**](https://github.com/vercel/next.js/pull/66262)
    

열심히 작업해서 리뷰 요청했다.

### [S](https://github.com/vercel/next.js/pull/66262)[WC ES 파서 feature](https://github.com/vercel/turbo/pull/8221)

* [https://github.com/sw](https://github.com/vercel/turbo/pull/8221)[c-](https://github.com/vercel/next.js/pull/66262)[p](https://github.com/swc-project/swc/pull/9019)[roject/swc/pull/9019](https://github.com/vercel/next.js/pull/66262)
    
    * [https://github.com/v](https://github.com/vercel/next.js/pull/66262)[ercel/turbo/pull/8287](https://github.com/vercel/turbo/pull/8287)
        
* [https://github.com/vercel/next.js/pull/66521](https://github.com/vercel/next.js/pull/66521)
    

SWC 파서가 elk.js 파싱할 때 60GB의 메모리를 할당한다는 얘기를 듣고 디버깅을 해봤다. 근데 재현이 안 됐다.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1717496058307/05c3f8cd-39e3-463e-88fe-6cbc6269ad78.png align="center")

9.64GB도 충분히 많이 쓰는 것이라서 콜 스택을 봤더니, 내가 프로파일링 할 때 SWC의 테스팅 시스템을 이용해서 그렇게 나오는 것이었다.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1717496101330/d7543159-4dac-41d1-b75a-b56ddbd9dd47.png align="center")

테스팅 시스템을 없앤 뒤 프로파일링하자 `256.10MiB`를 사용했고, 여전히 마음에 들지 않아서 콜스택을 한번 더 읽어봤다.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1717496139230/542aa23a-aa01-48b6-a49b-46d316dda6a8.png align="center")

`criterion`이 `256MiB`를 쓰고 있었고, 파서가 쓰는 메모리는 `0.10MiB`였다. 근데 팀원들이 프로파일링한 방식을 보니까 `swc_ecma_parser/debug`라는 cargo feature을 활성화한 것 같았는데 저 기능은 파서 자체를 디버깅하기 위한 기능이라서 로그를 엄청나게 추가한다. 그게 60GB의 원인인 것 같아서 빠르게 고치고 next.js와 터보팩에도 PR을 보냈다.

### 회의

위의 이슈와 관련해서 팀 회의에 참여했다.