비교할 문제
Context 광범위 재렌더에서 확인할 질문은 Context value 변경이 실제로 어느 consumer까지 다시 render하게 만드는가입니다. 같은 context 값과 UI를 제공하고 consumer 수·update 빈도와 provider value identity를 같게 둡니다. 결과값, 순서, 오류 처리와 부수 효과가 다르면 같은 성능 비교가 아닙니다. 먼저 두 후보가 같은 일을 하는지 작은 입력으로 확인합니다.
원인 분석과 재현
Provider value identity가 바뀌면 해당 Context를 읽는 consumer가 갱신되므로 state를 분리하고 value를 안정화할 필요가 있습니다.
consumer 10·1,000개, 자주 바뀌는 값과 거의 고정된 값을 나눠 commit 수, actualDuration과 interaction latency를 기록합니다. runtime version, 운영체제, CPU와 memory 제한도 결과와 함께 기록합니다.
비교 질문은 Context value 변경이 실제로 어느 consumer까지 다시 render하게 만드는가입니다.
| 후보 | 유리한 조건 | 함께 치르는 비용 |
|---|---|---|
| 단일 Context | 작고 함께 바뀌는 값 | 한 값 변경이 넓은 consumer update를 유발 |
| Context 분리 | 변경 빈도와 소비자가 다른 값 | provider와 public API 수 증가 |
| selector가 있는 external store | 큰 공유 상태의 일부 slice 구독 | 별도 store·subscription 계약 |
<Profiler id="Consumers" onRender={(_, phase, actualDuration) => {
samples.push({ phase, actualDuration });
}}>
<ThemeContext.Provider value={themeValue}>
<SessionContext.Provider value={sessionValue}>{children}</SessionContext.Provider>
</ThemeContext.Provider>
</Profiler>
해결 방안과 판정
warm-up과 측정 구간을 나누고 여러 번 반복합니다. 서비스 지연은 median과 p95를, 처리량 비교는 단위 시간당 완료 수와 오류율을 함께 기록합니다. CPU time, allocation, RSS·heap, GC, I/O 중 이 작업에 직접 관련된 지표만 선택합니다. Context는 무조건 느린 API가 아닙니다. 실제로 자주 바뀌는 value와 그것을 읽는 consumer 범위가 병목일 때만 분리 효과를 채택합니다.
차이가 반복 실행의 흔들림보다 작다면 더 단순하고 읽기 쉬운 구현을 선택합니다. 차이가 충분히 크더라도 실제 요청 전체의 지연과 자원 사용이 개선되는지 확인한 뒤 적용합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.