Profiler에서 CPU 병목과 GC Alloc을 찾는 순서

‘느리다’를 프레임 시간으로 나눠 보기

Profiler는 앱이 프레임마다 어디에 시간을 쓰는지 보여 줍니다. 문제가 다시 나타나는 장면을 먼저 고정하고, 병목 후보를 찾은 뒤 가설을 하나씩 바꿔 봅니다.

에디터 수치만 보고 결론 내리지는 마세요. 목표 기기와 비슷한 환경에서도 같은 문제가 나타나는지 다시 확인해야 합니다.

처음 30분은 이 순서로 본다

처음부터 모든 모듈을 읽으려 하지 마세요. 프레임 시간을 가장 많이 차지하는 구간부터 좁혀 가는 게 빠릅니다. GC 할당은 CPU Usage의 프레임별 샘플과 Memory 모듈의 장기 추세를 서로 다른 지표로 봐야 합니다.

1. 문제가 발생하는 같은 장면과 조작을 반복할 수 있게 만듭니다.
2. CPU Usage에서 문제 프레임을 고르고 PlayerLoop 아래의 가장 큰 항목을 엽니다.
3. Hierarchy의 GC.Alloc 열과 Timeline의 자홍색 GC.Alloc 샘플을 확인합니다.
4. Allocation Call Stacks를 켜고 같은 동작을 다시 실행해 managed allocation 호출 지점을 찾습니다.
5. GPU 또는 Rendering 지표를 함께 보며 CPU 대기인지 렌더링 병목인지 가설을 세웁니다.
6. Memory의 GC allocated in frame과 Managed Heap 크기를 구분합니다. Heap이 커진 채 유지된다는 사실만으로 누수라고 판정하지 않습니다.
7. 한 가지 변경만 적용하고 목표 기기의 Development Build에서 같은 시나리오를 다시 측정합니다.

Deep Profile은 후보를 좁힌 뒤에

Deep Profile은 세부 호출을 보여 주지만 측정 자체의 부담도 큽니다. GC 할당 지점만 찾는다면 먼저 Allocation Call Stacks를 쓰세요. Deep Profile은 일반 Profiler와 호출 스택으로도 원인을 좁히지 못한 짧은 구간에만 켭니다.

‘FPS가 올랐다’고 끝내지 말고, 어떤 시나리오에서 프레임 시간의 어느 구간이 얼마나 줄었는지 적어 둡니다. 그래야 다음 최적화를 어디서 시작할지 바로 알 수 있습니다.