메모리 사용량이 줄었다는 숫자만으로는 무엇을 바꿨는지 알 수 없다. 북극성의 과거 비교는 같은 스무 개 탭을 저장하되 처음에 불러오는 문서 수를 달리한 시험이었다. 나는 당시 표본과 현재 측정기 코드를 다시 읽고 수치를 재계산하면서 그 조건을 글의 일부로 남겼다.
같은 목록이지만 실행한 문서 수는 다르다
0.1.61과 0.1.62의 독립 시험 프로필에는 같은 스무 개 로컬 시험 URL과 같은 시작 선택을 넣었다. 새 버전은 탭 목록 전체를 보여 주되 한 문서만 로드했고 나머지 열아홉 개 renderer PID가 0이었다. 실제 웹사이트 스무 개를 모두 활성화한 상태끼리 비교한 표는 아니다.
이 차이는 실험의 결함을 감추는 조건이 아니라 지연 로딩이라는 변경이 무엇을 했는지 설명하는 조건이다. 모든 문서를 동시에 켜 놓고도 같은 양이 줄었다고 말하면 다른 결과가 된다. 탭 수와 renderer 수, 시작 선택과 자료의 종류가 함께 있어야 독자가 자기 업무와 비교할 수 있다.
전용 RAM과 작업 집합을 같은 합계로 부르지 않는다
measure-memory는 명시한 부모 PID와 하위 프로세스를 읽어 USS·전용 커밋·작업 집합을 각각 더한다. 결과 표에서 비교한 전용 RAM은 USS이며 공유 페이지를 포함한 작업 집합 합계와 다른 지표다. 이름이 모두 MiB라고 같은 메모리 수치가 되는 것은 아니다.
측정기는 프로세스 정체성을 확인하기 위해 생성 시각도 비교한다. 도중에 종료됐거나 접근이 거절된 자식은 건너뛰므로 그 경우 전체를 빠짐없이 읽었다고 단정할 수 없다. 저장 표본의 집계 프로세스 수는 이전 25개와 이후 6개로 남아 있다. 표본의 프로세스 수와 조건을 함께 보는 이유다. 다른 프로그램을 종료하거나 작업 집합을 강제로 줄여 숫자를 만드는 명령은 이 측정기에 없다.
안정화와 여러 표본 뒤 평균을 냈다
시작 시험은 15초 안정화 뒤 측정기를 호출하고 3초 간격으로 일곱 표본을 남긴다. 현재 측정기 자체의 대기 인자와 시험 바깥의 안정화 위치도 구별했다. 같은 15초를 두 번 기다린 것으로 읽지 않도록 실행 코드를 함께 봤다. 한 번 순간적으로 낮아진 값만 뽑지 않았다.
원자료를 다시 계산한 전용 RAM 평균은 약 562.75MiB와 225.10MiB, 전용 커밋은 864.60MiB와 337.25MiB였다. 이것은 이번에 새로 측정한 RAM이 아니라 기존 일곱 표본의 재계산이다. 원본 파일의 해시와 계산 결과도 비공개 근거로 남겨 과거 보고서의 반올림 수치와 대조했다.
사용자 환경의 전후 숫자는 다른 질문이다
과거 보고서에는 실제 사용자 실행의 전후 수치도 있다. 그러나 실행 시간과 페이지 상태, 운영체제 메모리 압력이 다르므로 같은 조건의 시작 시험과 합쳐 고정 절감률을 만들지 않는다. 원래 로그인이나 원고가 남았는지를 확인하는 보존 검수와 메모리의 원인별 비교도 별개다.
메모리 누수와 장시간 내구, 모든 사이트의 동영상·WebSocket·WebRTC 상태가 이 작은 시작 시험으로 검증되는 것도 아니다. 페이지를 다시 불러오므로 어떤 임시 상태를 잃는지도 함께 설명해야 한다. 나는 낮은 숫자 하나를 제품 전체의 우위로 바꾸기보다 확인한 자원 변화와 미확인 조건을 나란히 읽는 편을 택했다.
캐시 한도 시험은 프로세스 측정의 대체물이 아니다
공유 모듈에서 캐시 바이트가 줄어드는 것은 직렬화한 읽기 자료의 보관량이다. 실제 renderer RAM과 같지 않다. 모듈은 탭을 닫지 않고 메모리 측정도 하지 않는다. 숫자 필드가 있다는 이유로 서로 다른 계층의 시험 결과를 합쳐 표시하지 않았다.
이번 글에서는 코드·과거 결과·저장 표본을 읽고 산술만 새로 확인했다. 실제 북극성이나 사용자의 다른 프로세스는 실행·종료하지 않았다. 다른 프로그램의 개선을 설명할 때도 같은 자료와 같은 시작 상태, 지표와 표본 수를 남기면 된다. 측정 조건까지 함께 공개해야 제작자의 선택이 어떤 편의와 한계를 만들었는지 이해할 수 있다.