Establish native micro runtime checkpoint

1 files changed, 57 insertions, 0 deletions

diff --git a/docs/research/065-native-save-latency.md b/docs/research/065-native-save-latency.md
new file mode 100644
index 0000000..1789ee2
--- /dev/null
+++ b/docs/research/065-native-save-latency.md
@@ -0,0 +1,57 @@
+# 065 — 실제 네이티브 편집기의 1바이트 저장 완료 시간
+
+큰 문서의 작은 수정에서 페이지 저장소가 CLI 실험 밖에서도 유용한지 확인했다.
+같은 빌드 시 준비된 `editor.pure`와 네이티브 TUI를 기본 불변 파일 저장소,
+선택형 16 KiB 하이브리드 페이지 저장소에 각각 연결했다. 입력·커서·화면은
+같은 코드다. TUI에서 마지막 문자를 바꾸고 Ctrl+S를 보낸 순간부터
+**내구성 저장 완료가 화면에 표시된 프레임**까지 측정했다. 이 시간에는 초안
+비교, Pure 실행, 파일 `fsync`, 화면 갱신이 포함된다. 최초 문서 생성과
+사후의 독립 CLI 읽기는 제외했다. 매 세션의 최종 본문과 리비전은 그 CLI로 확인했다.
+
+2026-09-24 Linux AArch64, ext4 `/dev/mmcblk0p2`에서 256 B와 1 MiB 문서별로
+각 저장소를 세 세션씩 열고 세션마다 8회 수정했다. 저장소 순서를 세션마다
+뒤집었다. 아래 수치는 저장소·문서 크기별 **24회**의 중앙값이다.
+[측정 코드](../../research/experiments/006-native-save-latency/measure.py)와
+[매회 시간·실행물 해시·최종 본문 해시](../../research/experiments/006-native-save-latency/2026-09-24-ext4-linux-aarch64.json)를
+남겼다.
+
+| Ctrl+S → 저장 완료 표시 | 기본 파일 | 선택형 페이지 |
+|---|---:|---:|
+| 256 B 문서의 마지막 1 B 수정 | 8.54 ms | 9.23 ms |
+| 1 MiB 문서의 마지막 1 B 수정 | 93.17 ms | 22.04 ms |
+
+1 MiB의 세 세션별 중앙값은 기본 93.19·93.83·92.17 ms, 페이지
+21.34·22.04·22.86 ms였다. 이 작업에서는 약 **4.2배** 차이가 났다.
+256 B에는 페이지 경로의 이득이 없다. 최대 지연도 각각 349.60·97.70 ms로
+흔들렸으므로 꼬리 지연의 보편적 상한은 주장하지 않는다. 장치의 캐시·동시
+작업·온도는 통제하지 않았다.
+
+비용도 따로 기록했다. 같은 Linux 빌드의 고정 정의 TUI 링크 `text`는
+**32,079→37,021 B** (+4,942 B), 소스 정의 TUI는 **48,684→53,642 B**
+(+4,958 B)다. 현재의 소스 CLI+TUI 압축 묶음은
+[기본 51,117 B](../../prototypes/connections/results/2026-09-24-native-save/pure-document-flat-cli-tui-linux-aarch64.tar.gz)와
+[선택형 페이지 57,788 B](../../prototypes/connections/results/2026-09-24-native-save/pure-document-hybrid-cli-tui-linux-aarch64.tar.gz)다.
+각각 [기본형](../../prototypes/connections/results/2026-09-24-native-save/flat-package-check.json)과
+[페이지형](../../prototypes/connections/results/2026-09-24-native-save/package-check.json)을
+분리된 디렉터리에서 검증했다.
+선택형 CLI+TUI 묶음을 다시 생성해도 SHA-256
+`b3c156eb7880ee4cb91b3fe52854cb5069ef035d082b7d539fa2a79592247ec5`로 일치했다.
+실제 [소스 TUI 검사](../../prototypes/connections/results/2026-09-24-native-save/hybrid-source-tui.json)는
+1 MiB 편집·UTF-8·충돌·1,024개 문서 조작을 통과했고, 한 실행의 피크 RSS는
+3,200 KiB였다. [기본형의 별도 실행](../../prototypes/connections/results/2026-09-24-native-save/flat-source-tui.json)은
+3,216 KiB였다. 이 한 번씩의 RSS로 미세한 메모리 우열을 판정하지 않는다.
+
+선택형 패키지는 `.pure`를 실행 때 읽어 정의를 바꿀 수 있다. 작은 문서는
+기존 `PUREB001`이고 큰 문서는 `PUREP001`이 된다. 기본 저장기는 큰 페이지
+문서를 직접 읽을 수 없으므로 별도 저장소에서 사용하고, 기본 형식으로 돌아갈
+때는 [오프라인 내보내기](062-paged-store-rollback.md)를 거쳐야 한다.
+16 KiB OS 페이지가 필요한 이 실험은 Linux에서만 실행했고 macOS는 미검증이다.
+기본 코어와 기본 TUI는 변경하지 않았다. 이 비용·형식 경계 때문에 페이지
+저장소는 **명시적 선택 기능**으로 유지한다.
+
+최신 [소스 배포본](../../prototypes/connections/results/2026-09-24-native-save/pure-source-preview.tar.gz)은
+171개 파일, 압축 333,925 B다. [다른 디렉터리의 깨끗한 빌드](../../prototypes/connections/results/2026-09-24-native-save/source-package-check.json)에서
+이 선택형 TUI의 빌드·실제 문서 작업·패키징·이동 후 검사를 기본 C·PTY·전달·
+내보내기·Linux 릴리스 검사와 함께 통과했다. 별도 생성한 소스 배포본도
+SHA-256 `b258788cc9f90d8e6eccc964c8c9f4e2c5460df3dfbb9da07268da07799691e4`로
+일치했다. 소스 압축 크기는 상주 메모리와 다르다.