Establish native micro runtime checkpoint

1 files changed, 54 insertions, 0 deletions

diff --git a/docs/research/061-durable-document-edit-latency.md b/docs/research/061-durable-document-edit-latency.md
new file mode 100644
index 0000000..e458d46
--- /dev/null
+++ b/docs/research/061-durable-document-edit-latency.md
@@ -0,0 +1,54 @@
+# 061 — 같은 불변 문서 편집의 완료 시간과 페이지 재구성 비용
+
+큰 문서의 1바이트 수정에서 기본 불변 파일, Linux `copy_file_range` 선택 경로,
+16 KiB 페이지 선택 저장소를 **같은 `editor.pure` 소스 CLI**로 비교했다.
+비교 코드는 [단일 수정](../../research/experiments/005-storage-edit-latency/measure.py)과
+[연속 수정](../../research/experiments/005-storage-edit-latency/sequence.py)에 있다.
+각 저장소에서 1 MiB 문서를 만들고, 새 CLI 프로세스로 마지막 1바이트를 리비전
+검사와 함께 바꾼다. 생성·수정은 각각 `fsync`를 포함한다. 이후 다른 프로세스의
+`show`로 전체 본문과 리비전을 확인한다. 측정값은 CLI 시작·`.pure` 준비·
+저장소 초기화까지 포함하고 검증용 `show` 시간은 제외한다.
+
+2026-09-24 Linux AArch64, ext4 `/dev/mmcblk0p2`에서 각 방식 18회씩,
+실행 순서를 순환해 측정했다. [모든 원자료](../../research/experiments/005-storage-edit-latency/2026-09-24-ext4-linux-aarch64.json)에
+실행물 해시·매회 완료 시간·최종 본문 해시·파일 할당량이 있다.
+
+| 실제 CLI 작업의 중앙값 | 기본 불변 파일 | 선택형 파일 간 복사 | 선택형 페이지 |
+|---|---:|---:|---:|
+| 1 MiB 새 문서 생성 | 83.556 ms | 81.672 ms | 88.948 ms |
+| 기존 문서 마지막 1 B 수정 | 78.805 ms | 77.908 ms | 14.473 ms |
+| 수정 후 파일 할당량 | 1,052,672 B | 1,052,672 B | 1,069,056 B |
+| CLI 링크 `text` | 35,783 B | 36,052 B | 41,040 B |
+
+별도 자식 프로세스 RSS 검사에서 1 MiB 생성 피크는 기본 2,080 KiB,
+파일 간 복사 2,080 KiB, 페이지 2,112 KiB였다. 1바이트 수정 피크는
+각각 1,104·1,056·1,056 KiB였다. 이 한 번씩의 값은 작은 차이의 우열을
+판정하지 못하지만 세 방식 모두 같은 규모의 전체 CLI 메모리를 사용했다.
+[기본](../../research/experiments/005-storage-edit-latency/flat-memory.json),
+[파일 간 복사](../../research/experiments/005-storage-edit-latency/copy-memory.json),
+[페이지](../../research/experiments/005-storage-edit-latency/paged-memory.json)의
+원시 단위·실행물 해시를 함께 남겼다.
+
+페이지 경로는 같은 회차의 기본 경로보다 16/18회, 파일 간 복사보다 17/18회
+짧았다. 그러나 한 번은 565.5 ms로 길었다. 파일 간 복사는 사용자 공간 호출을
+줄이지만, 이 환경의 완전한 내구성 편집 시간에서는 기본 경로와 구분되는
+중앙값 이득을 보이지 않았다. 이를 보편적인 처리량 결과로 확장하지 않는다.
+
+한 문서를 70번 연속 수정하는 [원자료](../../research/experiments/005-storage-edit-latency/2026-09-24-sequence-ext4-linux-aarch64.json)에서는
+기본 파일 83.176 ms, 페이지 저장소 18.858 ms가 중앙값이다. 페이지가 같은
+수정 회차에서 더 짧은 경우는 59/70회였다. 64회차까지 페이지 세그먼트의
+할당량이 2,101,248 B로 증가했고, **65회차에 재구성**되며 1,052,672 B로
+내려갔다. 이번 재구성은 35.067 ms였으나 다른 회차에 219.485 ms 지연이
+발생했다. 즉, 재구성만이 긴 지연의 원인은 아니다. 저장 장치의 캐시·동기화·
+백그라운드 작업을 통제하지 않았으므로 꼬리 지연 상한은 제시할 수 없다.
+
+현재 선택형 페이지 저장소의 [전체 검사 기록](../../research/experiments/005-storage-edit-latency/2026-09-24-check-hybrid.log.gz)은
+앱 동작, 충돌·스냅샷·실패·재구성 C 검사와 Linux 코드·RSS 상한을 통과했다.
+페이지 저장소의 링크 `text`는 기본 CLI보다 **5,257 B 크다**. 기본 코어는
+변경하지 않았다. 또한 기존 기본 저장소는 새 페이지 형식을 직접 읽지 못하고,
+선택형 저장소는 OS의 16 KiB 페이지 크기를 요구한다. 이후
+[오프라인 형식 내보내기](062-paged-store-rollback.md)는 확인했지만 macOS 실행과
+운영 중 투명한 전환은 검증하지 못했다. 따라서 지금은 페이지 저장을 **선택형 연구
+프로필**로 유지하고, 이 실측 결과를 형식 전환·복구 설계의 우선순위 근거로
+사용한다. 작은 문서의 쓰기량, 충돌, 오래된 읽기와 실패 계약은
+[기존 하이브리드 기록](034-hybrid-document-storage.md)에 있다.