10차 D-1 기록: 첫 폴더 비교 9.2초는 캐시를 비워도 다시 안 남 - 고치지 않음

파일마다 버퍼 없이(FILE_FLAG_NO_BUFFERING) 열었다 닫아 캐시를 비운 뒤 쟀다
(한 갈래 읽기 0.4 → 1.8초로 먹는 것 확인).

- 4,500개 묶음 전체 비교: 데운 상태 479ms, 캐시 비운 뒤 535 · 455 · 494ms (여러 갈래 읽기)
- 크기 같은 4,063쌍 읽기: 갈래 1 1,775ms · 4 583 · 16 318 · 32 305 · 64 332
- 앱을 캐시 비우고 새로 켠 첫 [비교]도 1.0~1.8초(누름 대기 포함) - 둘째와 같음
- 9.2초는 다시 안 남(디스크 정보 캐시 · 백신 짐작) - 제품 코드 변경 없음
- 웹 문서 "알아 둘 한계" 를 잰 값으로 고침(발행은 E-2)
- NVMe SSD 에서만 잼, HDD 는 재 보지 않음

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

doc/history/2026-09-17-10차.md

@@ -172,3 +172,55 @@
 ### 남긴 것
 
 - 규칙을 끈 두 칸 비교에서 주석 줄이 끼어들면 정렬이 한 줄씩 밀리는 것(위 표의 `Speed3` ↔ `Speed2`)은 규칙을 끈 이상 비교 키가 없어 생기는 모양이라 그대로 둔다. 기본값(켬)에서는 나지 않는다.
+
+## D-1. 그날 첫 큰 폴더 비교가 9.2초 (2026-09-17, 완료 · 고치지 않음)
+
+**9.2초는 다시 나지 않았다.** 파일 캐시를 비운 첫 비교도 0.5초 안팎으로 데운 상태와 같았다. 줄일 자리가 없어 제품 코드는 바꾸지 않았고, 매뉴얼 "알아 둘 한계" 를 잰 값으로 고쳤다.
+
+### 무엇으로 쟀나
+
+- 5차 B-2 시험 묶음(`%TEMP%\mergehub-perf`, 4,500개 · 양쪽 8,922개 · 136MB). 이 PC 디스크는 **NVMe SSD**(INTEL SSDPEKNU010TZ) · 논리 CPU 16개.
+- **차가운 상태 만들기**: 재부팅 · 시스템 도구(대기 메모리 비우기)는 쓰지 않았다. 파일마다 **버퍼 없이(`FILE_FLAG_NO_BUFFERING`) 한 번 열었다 닫아** 그 파일의 캐시를 비웠다.
+  먹는지 먼저 확인: 크기가 같은 4,063쌍을 한 갈래로 읽기 — 데운 뒤 407 · 386ms → **비운 뒤 1,808ms** → 곧바로 다시 396ms. 먹는다.
+- 측정 프로그램 `ColdPerf`(앱의 `FolderComparer` 를 그대로 컴파일, 앱 코드 변경 없음) · 앱에서는 비운 뒤 새로 켜서 [비교](`d9-b2.ps1`).
+- 백신 CPU 시간도 재려 했으나 `MsMpEng` 프로세스 시간은 권한 때문에 읽히지 않았다(설정은 건드리지 않음).
+
+### 잰 값
+
+| 경우 | 전체 비교 | 빠른 비교(크기 · 수정일) |
+|---|---|---|
+| 데운 상태 | 479ms | 159ms |
+| 캐시 비운 뒤 1 · 2 · 3회 | **535 · 455 · 494ms** | 172 · 154 · 193ms |
+| 비운 뒤 곧바로 한 번 더 | 562 · 406 · 475ms | - |
+
+결과 요약은 모든 경우 글자 하나까지 같았다(`전체 4500개 · 다름 359(주석만 294) · 왼쪽만 40 · 오른쪽만 38 · 같음 4063`).
+
+크기가 같은 4,063쌍을 **끝까지 읽기만**(캐시 비운 뒤, 갈래 수별):
+
+| 갈래 | 1 | 4 | 16(논리 CPU 수) | 32 | 64 |
+|---|---|---|---|---|---|
+| ms | 1,775 | 583 | 318 | 305 | 332 |
+
+앱(비운 뒤 새로 켬, 자동 조작으로 누른 때부터 요약이 뜰 때까지 — 누름 뒤 0.6초 대기 포함):
+
+| 회 | 첫 [비교] | 둘째 | 셋째 |
+|---|---|---|---|
+| 1 | 1,760ms | 1,457ms | 1,414ms |
+| 2 | 1,051ms | 1,459ms | 1,458ms |
+
+### 판단
+
+- **파일 캐시가 비어도 여러 갈래로 읽어서 몇백 ms 차이에 그친다**(한 갈래였다면 0.4 → 1.8초). 폴더 비교는 이미 64개가 넘으면 여러 갈래로 가린다(5차 B-2).
+- 앱을 새로 켠 직후 첫 비교도 느리지 않다 — 앱 쪽 첫 실행 값(JIT 등)도 아니다.
+- 9차 B-2 의 9.2초는 **며칠 손대지 않은 묶음을 그날 처음** 비교한 값이었다. 파일 캐시 말고 남는 것은 디스크 정보(폴더 목록 · MFT) 캐시, 백신 검사(서명 갱신 뒤 다시 검사 등)인데
+  둘 다 재부팅이나 시스템 · 보안 설정 없이는 다시 만들 수 없어 가리지 못했다.
+- **고치지 않는다.** 다시 나지 않는 것을 짐작으로 고치지 않는다(공통 규칙). 결과가 바뀌는 길(빠른 비교를 기본으로)은 하지 않는다.
+
+### 고친 것 (문서)
+
+- 웹 문서 매뉴얼 "알아 둘 한계" — "첫 비교 9.2초 · 두 번째부터 0.7초" 를 잰 값(캐시 비운 첫 비교도 약 0.5초, 한 갈래라면 0.4 → 1.8초, 9.2초는 한 번 났으나 다시 안 남, HDD 는 재 보지 않음)으로. 발행은 E-2 에서 함께 한다.
+
+### 남긴 것
+
+- **느린 디스크(HDD · SATA SSD)에서는 재 보지 않았다.** 이 PC 는 NVMe 뿐이다. 한 갈래 1.8초가 여러 갈래로 0.3초가 된 것은 NVMe 가 동시 읽기에 강해서이고,
+  HDD 에서는 여러 갈래 읽기가 오히려 느릴 수 있다. 사내 PC 가 HDD 라면 베타 배포 때 재 볼 거리다.

doc/history/changelog.md

@@ -8,6 +8,7 @@
 
 | 날짜 | 항목 | 커밋 |
 |---|---|---|
+| 2026-09-17 | **10차 D-1** — 9차 B-2 에서 한 번 잰 "그날 첫 폴더 비교 9.2초" 를 다시 냈다. 파일마다 버퍼 없이 열어 캐시를 비워도(한 갈래 읽기 0.4 → 1.8초로 먹는 것 확인) 전체 비교는 0.46~0.54초로 데운 상태와 같았고(여러 갈래 읽기), 앱을 새로 켠 첫 비교도 느리지 않았다. 9.2초는 다시 안 남 → 고치지 않음(제품 코드 변경 없음). 매뉴얼 한계 문장을 잰 값으로 고침. HDD 는 재 보지 않음 | 아래 |
 | 2026-09-17 | **10차 C-1** — 설정 "머지 주석 무시" 를 끈 채 네 칸을 다시 정렬하면 주석 줄이 BASE 코드 줄과 한 행이 되어 반영 표시(BASE 줄 번호)가 주석 줄에, 반영한 코드 줄은 "직접 수정" 으로 보였다. 네 칸은 규칙과 상관없이 주석 줄과 코드 줄을 떼어 놓고, 다시 정렬한 주석 줄을 "반영함" 으로 칠하지 않게 함. 요약 · 줄 수 · 저장 해시 그대로. 두 칸도 떼어 보니 차이 수가 늘어(4 → 5줄) 두 칸은 그대로. 하네스 NoteTest +5 | 아래 |
 | 2026-09-17 | **10차 B-1** — Git 탭과 파일 비교 탭이 고른 커밋 값을 함께 쓰는데 표시는 새로고침 전까지 서로 안 따라왔다. 파일 비교 탭에서 고르면 Git 탭은 옛 커밋에 선택 표시가 남은 채 **[Revert] 가 보이지 않는 커밋에 걸렸다.** 사용자 결정대로 양방향으로 바로 따라가고(`CommitChosen`), 파일 비교 탭에 저장 안 한 편집이 있으면 Git 탭 목록이 선택을 바꾸기 전에 물어 [취소] 면 누름을 막는다. 하네스 +4 | 아래 |
 | 2026-09-17 | **10차 A-1** — 9차 D-1 N1(네 칸에서 고르기 한 번이 안 남아 멈춤)을 앱 안 임시 로그(잰 뒤 되돌림)와 함께 61회 · 누름 366번(병합 · cherry-pick × 9차 간격 · 0.1초) 되풀이 — 다시 안 남, 앱은 Take 372번 모두 충돌 줄에서 받아 하나씩 줄임(헛돈 0). Take 뒤 [다음 충돌] 처리 전에는 Take 단추가 꺼져 있는데 9차 시험 도구가 "꺼져서 안 누름" 을 버린 것으로 보임. 제품 코드 변경 없음, 시험 도구가 다시 누르고 못 누르면 적게 고침 | 아래 |

doc/web/index.html

@@ -556,7 +556,7 @@ Accept Theirs (상대 쪽 파일 그대로) 15
         <li>파일 단위 <span class="btn-label">Accept Mine</span> / <span class="btn-label">Accept Theirs</span> 는 고른 쪽 파일을 <b>바이트째</b> 쓴다. 상대가 줄끝을 바꾼 파일이라면 그 줄끝이 그대로 들어온다 — 줄끝을 지키려면 네 칸에서 줄로 고른다.</li>
         <li>병합 커밋 본문의 해결 내역은 <b>MergeHub 에서 푼 충돌만</b> 적힌다. 터미널에서 푼 파일은 빠지므로, 본문 건수가 처음 충돌 수보다 적으면 그만큼은 밖에서 푼 것이다.</li>
         <li>빠른 비교(크기 · 수정일)는 내용이 바뀌었는데 크기와 시각이 같은 파일을 놓친다.</li>
-        <li>그날 처음 하는 큰 폴더 비교는 디스크에서 파일을 처음 읽느라 오래 걸린다 — 4,500개 묶음에서 첫 비교 9.2초, 두 번째부터 0.7초.</li>
+        <li>큰 폴더의 전체 비교는 크기가 같은 파일을 끝까지 읽는다. 4,500개 묶음(NVMe SSD · 16코어)에서 파일 캐시를 비운 첫 비교도 약 0.5초로 데운 상태와 거의 같았다 — 여러 갈래로 읽기 때문이다(한 갈래라면 0.4초 → 1.8초). 며칠 손대지 않은 묶음을 처음 비교할 때 한 번 9.2초가 났으나 다시 나지 않았다(원인은 가리지 못함 — 디스크 정보 캐시 · 백신 검사로 짐작). 느린 디스크(HDD)에서는 재 보지 않았다.</li>
         <li>Git 탭 이력에서 커밋을 고르면 파일 비교 탭의 Selected Commit 은 <span class="btn-label">새로고침</span> 전까지 따라오지 않는다. 파일 비교 탭 왼쪽 이력에서 고르면 바로 바뀐다.</li>
         <li>설정에서 “비교 · 병합에서 머지 주석 무시” 를 끈 채 네 칸을 다시 정렬하면(타이핑 멈춤 · 규칙 변경) 반영 색이 옆 줄로 옮겨 보일 수 있다. 저장 내용과 범례 수는 같다. 기본값(켬)에서는 나지 않는다.</li>
         <li>코드 검사는 빌드가 된다는 보증이 아니다.</li>

doc/진행상황.md

@@ -304,7 +304,7 @@
 
 | 상태 | 항목 |
 |---|---|
-| 대기 | D-1 그날 첫 큰 폴더 비교가 9.2초 (재고 정함) |
+| **완료** | D-1 그날 첫 큰 폴더 비교가 9.2초 — 고치지 않음. 파일마다 버퍼 없이 열어 캐시를 비운 뒤 재도(한 갈래 읽기 0.4 → 1.8초로 먹는 것 확인) 전체 비교 0.46~0.54초로 데운 상태(0.48초)와 같음 — 여러 갈래로 읽어서. 앱 새로 켠 첫 비교도 느리지 않음. 9.2초는 다시 안 남(디스크 정보 캐시 · 백신 짐작, 재부팅 · 보안 설정 없이 못 만듦). 매뉴얼 한계 문장을 잰 값으로. HDD 는 재 보지 않음 |
 
 ### E. 확인 · 문서