3D 도시 파일이 19.9MB였다. 웹에서 돌리기엔 무겁고, 그리기 호출도 19,486번이라 프레임이 버거웠다.
소품을 많이 심었으니 그런 줄 알았다. 소품을 줄이거나 형상을 단순화하는 다이어트를 계획했다.
다이어트 전에 어디가 무거운지 쟀다
파일 안에서 뭐가 용량을 먹는지 항목별로 재봤다. 그런데 이상했다. 같은 벤치가 수백 개 있으면 형상 하나에 위치 목록만 있으면 된다. 원본 씬은 실제로 그렇게 묶음(인스턴싱)으로 되어 있었다.
그런데 내보낸 파일에는 벤치 수백 개가 각각 통째로 들어 있었다. 내보내기 과정이 원본의 묶음을 풀어서, 같은 형상을 수백 번 복사해 담고 있었던 것이다.
무거운 건 소품이 아니라 풀린 포장이었다.
포장을 유지하니 5분의 1이 됐다
내보내기에서 묶음이 풀리지 않게 고쳤다. 결과는 19.9MB → 3.9MB. 그리기 호출은 19,486 → 1,843. 소품은 하나도 안 뺐다. 화면은 그대로다.
함정이 하나 더 있었다. 내보낼 대상을 고를 때 빈 껍데기 노드를 빼면, 그 아래 묶여 있던 17,750개 인스턴스까지 통째로 풀린다. 최적화하려던 선택이 최악을 만드는 경로였다.
증상의 주인을 먼저 찾는다
소품 다이어트부터 했다면 품질만 깎이고 용량은 그대로였을 것이다. “무겁다”는 증상에서 바로 “줄이자”로 가지 말고, 무게의 주인이 누구인지부터 재야 했다.
재발방지 체크리스트
① 용량·성능 문제는 줄이기 전에 항목별로 무게를 잰다. 주인이 따로 있는 경우가 많다.
② 원본과 산출물의 구조가 같은지 확인한다. 변환이 구조를 풀어버릴 수 있다.
③ 같은 것이 반복되면 복사가 아니라 참조로 담겨 있는지 본다.
④ 최적화 후에는 화면이 그대로인지와 수치가 줄었는지를 둘 다 잰다.
① 용량·성능 문제는 줄이기 전에 항목별로 무게를 잰다. 주인이 따로 있는 경우가 많다.
② 원본과 산출물의 구조가 같은지 확인한다. 변환이 구조를 풀어버릴 수 있다.
③ 같은 것이 반복되면 복사가 아니라 참조로 담겨 있는지 본다.
④ 최적화 후에는 화면이 그대로인지와 수치가 줄었는지를 둘 다 잰다.