먼저 제가 이번 이슈로 어떤 insight를 얻게 되었는지 요약해보겠습니다.

<aside> 💡 3줄 요약

1. 리코일 selector에 무분별한 promise를 남발하지 말라.
2. promise,setTimeout은 브라우저에서 병렬처리를 해주는 것이 아니다.
3. 마이크로태스크큐에 많은 작업을 넣지 말라

</aside>

제가 어떤 생각으로 문제를 파악하고 해결해나가는지 순서대로 설명해보겠습니다.

처음에는 성능이슈를 느끼지 못하였지만, 기능들이 완성되고 셀프 QA를 진행하는 도중에 개발중인 페이지가 켜지면 맥북의 쿨러가 심각하게 돌아가는것을 인지하였고, 저사양 PC에서는 UI가 멈추는 증상을 발견하고, 성능탭에서 측정을 시작하였습니다.

(최악의 성능탭)

<aside> 💡 참고

빨간색 체크가 나오면 먼저 사용자에게 나쁜 사용자 경험을 준다고 보시면 되겠습니다. 브라우저는 16ms마다 (60hz기준) 랜더링함수를 실행하는데, 16ms안에 처리되면 사용자는 웹이 부드럽다 인식하고 100ms를 넘어서면 행동과 응답이 끊어졌다고 느끼기 시작한다. (브라우저 RAIL참고)

</aside>

최적화를 진행하기전에 리코일의 공식문서의 패치노트를 구경하면서 최근에 어떤 이슈가 있나 확인한 결과 힌트를 얻을 수 있었습니다. 힌트는 셀렉터의 캐쉬문제, 비동기 셀렉터의 메모리 누수 문제, 셀렉터의 무엇인가 문제가 있을수 있겠다라는 힌트를 얻을 수 있었습니다.

참조 링크 1.https://recoiljs.org/ko/blog/2022/03/25/0.7.0-release

먼저 소거법으로 어느 컴포넌트에서 해당 이슈가 발생하는지 찾아보았습니다.

불필요한 컴포너트는 주석 처리를 하고 Ticker가 보여지는 컴포넌트만 활성화시켜봤는데 안좋은 성능이 측정되었습니다. 문제의 원인이 이 컴포넌트에 있을 수 있겠다라는 가정으로 해당 컴포넌트에서 문제를 하나하나 해결해보겠습니다.

최적화 결과 먼저..

변경전

변경후

해당 성능이슈를 발생시킨 저의 코드를 보겠습니다.

해당 코드를 어떤 생각으로 작성하였냐면 , 복잡한 연산은 비동기로 브라우저에 연산을 시키면 되겠지? 라는 생각을 하여 promise를 사용하여 코드를 작성했지만. 결과는 충격적이였습니다

비동기코드(recoil selector)

동기코드(recoil seleter)

결과

recoil에서 연산 처리를 비동기에서 동기로 변경했을 뿐인데, 성능이 이렇게 바뀌었습니다. 리코일 selector 비동기코드는 무엇인가 자원을 더 잡아먹는것을 유추할 수 있었습니다.