From b1ce1927022d374198441afafeb27199fc8a052a Mon Sep 17 00:00:00 2001 From: eunhhu Date: Thu, 24 Sep 2026 17:14:54 +0100 Subject: Establish native micro runtime checkpoint --- docs/research/061-durable-document-edit-latency.md | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 docs/research/061-durable-document-edit-latency.md (limited to 'docs/research/061-durable-document-edit-latency.md') 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)에 있다. -- cgit v1.2.3