useMemo, useCallback에 대한 생각

경우에 따라 연산된 값이나 선언된 함수를 유지하는 것이 퍼포먼스에 도움이 된다고 한다.

예를 들면 이미 연산된 값이 있고, 어떠한 state가 변했더라도 해당 값이 변할 이유가 없다면 다시 렌더링됐을 때 해당 값이 다시 연산될 필요가 없지 않은가?

이런 경우에 useMemo나, callback이 사용된다.

구현된 코드를 살펴보면서 느낀 건데, 컴포넌트가 많아지면 많아질수록 '어쩔 수 없이' state들이 순환되는 구조를 가질 수 밖에 없는 것 같기도 하다.

state는 왔다리 갔다리

검색어가 입력될 때마다 그 결과가 검색바 밑에 표시된다고 가정해보자.

<SearchKeywordProvider>
  <SearchBar/>
  <SearchResult/>
</SearchKeywordProvider>

Keyword는 Provider에 담겨 하위 컴포넌트에 뿌려진다고 치자.

그렇다면 SearchBar에서 setKeyword가 호출되어 Keyword가 변경될 것이고

SearchResult에 그려질 것들은 filter를 거칠 것이다.

어라? Provider는 Context에 담긴 값의 변경 사항을 관측한다.
그러면 자식 컴포넌트인 Bar와 Result에 정의된 값과 함수들이 다시 생길텐데?

위의 코드만 보면 한 개의 Provider만 있으므로 사용할 필요가 없겠지만
Provider에 Provider에 Provider에....어쩌구저쩌구....되버리면 memo, callback이 필요하겠다라는 생각이 든다.

cost의 비교

메모이제이션을 쓰게 되면 일단 코드가 추가된다.

또한 값이나 함수를 메모리 영역에 적재해두고 해제하지 않으므로 메모리에 다소 비효율적일 수 있다.

다만 재연산되고, 재선언되는 그런 과정이 실제 성능에 유의미할 정도의 문제를 일으킨다면 채용하는 것이 좋겠다.

즉 현재 구현된 서비스의 퍼포먼스에 문제가 있다면 그 부분에 대한 비용을 먼저 체크한 뒤에 사용을 고려해야되는 것이 아닌가? 하는 생각이다.

또 사실, 내부적으로는 비효율적이더라도 사용자가 사용하기에 체감이 되지 않거나 평균적인 사용 시간보다 더 시간이 지나야만 발생하는 성능 저하라면 굳이? 사용할 필요가 없다고 생각한다.

어디선가 해외 아티클에서 봤던, 과한 최적화는 안하느니만 못하다는 글귀가 기억난다.