Say what a transient state saves a write (018 stage 1, research 117)

1 files changed, 53 insertions, 0 deletions

diff --git a/docs/research/117-transient-states.md b/docs/research/117-transient-states.md
new file mode 100644
index 0000000..5e5fe12
--- /dev/null
+++ b/docs/research/117-transient-states.md
@@ -0,0 +1,53 @@
+# 117 — 저장하지 않는 상태
+
+2026-10-04. [018](../design/018-lifetimes-and-computation.md)의 1단계(`transient state`)를 잰다. 1단계의 기준은 검사였고(018에
+구현 전에 적어 커밋했다, `4d93488`), 처리량은 기준 없이 밝히기로 했다.
+
+## 쉬운 말로
+
+- aup에서 `transient state`로 선언한 상태는 앱이 도는 동안만 있다. 다시 시작하면 초기값이고, 저장소에는 아무것도 쓰지 않는다.
+  실패한 이벤트에서 되돌리는 것, 보기에서 읽는 것, 메모리 예산에 드는 것은 다른 상태와 같다.
+- SD 카드에 저장소를 둔 점수판에서 저장하는 쓰기는 초당 7,598번이고, 같은 쓰기를 transient 상태에 하면 초당 132,305번이다
+  (17배). 저장하는 쓰기는 요청마다 장치에 약 1 KB를 쓰고, transient 쓰기는 0바이트를 쓴다.
+- 저장소가 RAM에 있으면 둘은 거의 같다(+1.5%, 흔들림 안). 저장이 원래 싸기 때문이다.
+
+## 결과
+
+원시 결과와 명령은 [032-transient-states](../../research/experiments/032-transient-states/)에 있다(`transient.py`).
+
+**방법.** 한 호스트(`--apps`, 연결 스레드 하나, 실행 스레드 둘, 코어 0–2)에 점수판(`benchmarks/http/scores.aup`) 둘: `stored`
+(그대로)와 `transient`(`board`가 transient 상태). 부하 도구(코어 3)가 16연결 keep-alive로 10초 동안 점수를 올린다(키 64개).
+둘을 번갈아 세 라운드다. 장치에 쓴 바이트는 호스트의 `/proc/PID/io`의 `write_bytes` 차이다.
+
+| 중앙값 | stored | transient |
+|---|---:|---:|
+| RAM(`/dev/shm`), 초당 요청 | 130,576 | 132,522 (+1.5%) |
+| SD 카드(`~/.cache`, ext4), 초당 요청 | 7,598 | 132,305 (17.4배) |
+| SD 카드, 요청마다 장치에 쓴 바이트 | 1,033 | 0 |
+
+SD의 저장하는 쓰기는 p50 1.5 ms, p99 7.2 ms이고 transient는 p50 116 µs, p99 168 µs다. RAM의 두 앱과 같다.
+
+**검사.**
+- `test-module`의 `transient_states`: 수, text, 리스트, 인덱스가 transient인 앱이 다시 시작하면 초기값이고 저장되는 상태는 그대로다.
+  실패한 이벤트는 transient도 되돌린다. transient만 바꾸는 이벤트는 저장 번호를 올리지 않는다. 스냅숏은 transient text를
+  복사해 읽는 쪽에 보인다. 모듈을 바꿔 저장되던 것을 transient로, transient를 저장되는 것으로 바꾸면 다시 시작한 뒤에 바뀐
+  대로다. 저장되지 않게 된 리스트를 다시 저장하면 저장소의 그 리스트는 저장되지 않게 된 때의 것이다(버린 상태를 다시 들인 것과
+  같다). transient 리스트를 가리키는 저장되는 인덱스를 가진 모듈은 로드가 거절한다.
+- Pure `tests/check.py`의 `server_transient`: `pure-serve`에서 같은 저장 요청 다섯 사이에 transient만 바꾸는 요청 100개(수,
+  리스트, text)를 섞어도 저장소의 파일과 바이트가 섞지 않은 것과 같다. 그 요청 100개는 저장소의 어떤 파일도 바꾸지 않는다.
+  transient text를 바꾼 직후 보기(스냅숏에서 읽는다)가 새 값을 답한다. `kill -9` 뒤에 다시 띄우면 transient는 초기값이고 저장되는
+  상태는 마지막 요청까지 있다.
+- aup `tests/check.py`의 `transients`와 진단 5건: 같은 앱의 transient 판과 저장 판의 모듈이 상태 타입 워드 세 바이트만 다르다.
+  `pure-run --store`에서 위와 같은 저장소 비교, 다시 열기, 모듈 교체.
+
+## 판정
+
+- **018의 1단계는 들어간다.** 상태의 영속성은 이제 aup의 선언이 정한다: `state`(저장), `transient state`(앱이 도는 동안),
+  `let`(이벤트 동안).
+- 저장소가 느린 기기에서 재시작 뒤에 뜻이 없는 상태(접속 수, 캐시, 진행 중 표시)를 transient로 두면 그 쓰기가 저장의 값을 내지
+  않는다.
+
+## 다음
+
+- 018의 2단계: 핸들러의 계산(이벤트의 리스트, 세는 반복, `break`, 중첩, 기본 예산).
+- transient text는 스냅숏마다 복사한다. 큰 transient text가 필요해지면 복사본을 스냅숏 사이에 나누는 것을 잰다.