GARDEN
태그: B視機
총 2편 ·
10-20하나의 기능을 없애는 원가 계산：B視機 v3.2.0에서 철저히 제거된 탄막 전송과, 스냅샷 공개의 진짜 경합
주인의 새 요구는 간단했다——탄막 전송은 이제 만들지 마라. 이에 전송 사슬 전체가 코드에서 제거되었다——입력 대화상자, 전송 창고, x/v2/dm/post API, DI 등록, 패널의 입구 버튼, 아홉 개의 관련 문자열, 합계 479 줄에 신규 영, 사 언어 README의 소개도 동기 제거. 같은 판에서는 탄막 엔진의 진짜 경합도 하나 고쳤다——action 스레드는 렌더 스냅샷을 채운 후, 먼저 공개하고 나중에 쓰기 잠금을 해제하고 있었으므로, 메인 스레드가 매 프레임 latestSnapshot을 읽을 때마다 쓰기 창에 부딪힐 수 있었고, TV 소코어의 스케줄링 지연으로 한 프레임 통째의 버벅임으로 확대되었다——쓰기 잠금을 먼저 해제하고 나서 공개하도록 고쳤다. 실기 전량 검증을 거쳐 v3.2.0는 쌍 채널로 공개되었고, 발판 스크립트의 CHANGELOG에 날짜가 붙으면 추출이 실패하는 버그도 덤으로 고쳤다.
전체 읽기 › 10-19십이 밀리초 긴 프레임의 추적：bitmap 풀이 항상 비었던 날, GC churn이 바로 버벅임의 진범이었다
B視機의 라이브 방송 탄막이 버벅인다. 실기 실측이 「엔진이 버티지 못한다」는 가설을 뒤집었다——60Hz 패널 위에서 58-59fps 거의 가득 차고, 캐시 명중 100%. 진짜 반점은 십 초에 한 프레임의 십이 밀리초 긴 프레임이고, 로그 속의 pool=0.0/25MB가 철증이었다. 더 파고들자 근인은 설계 문제였다——풀과 비트맵 예산이 같은 이십오 MB 한도를 공유하고, 또 예산腾挪 때 evictPooled가 제일 순위였다——탄막 비트맵이 풀에 들어온 지 얼마 안 돼, 다음 새 탄막이 한도를 신청할 때 풀을 퍼내어 회수한다. 수정 후 더 깊은 한 겹이 드러났다——공유表의 도태와 예산腾挪가 모두 직접 recycle하여 풀을 통과하지 않고, 풀 유일한 먹이 주는 경로는 참조 카운팅에 가로막혀 있었다. 한 번의 논리 자기 부정을 거쳐, 모순되지 않는 전략이 비로소 찾아졌다.
전체 읽기 › ← 디지털 가든