Say TPC-C's RAM numbers since snapshot nodes are reused

3 files changed, 8 insertions, 6 deletions

diff --git a/CHECKPOINT.md b/CHECKPOINT.md
index 57a2ee8..26f13b1 100644
--- a/CHECKPOINT.md
+++ b/CHECKPOINT.md
@@ -21,13 +21,14 @@
 | 메모리 한도 | 앱마다 상태의 예산이 있다(`--memory`). 목록의 항목, 텍스트, outbox, 들은 번호를 저장 형식의 바이트로 센다(어느 기기에서나 같다). 예산을 넘기며 늘리는 사건은 거절하고(503 `memory`) 줄이는 사건은 받는다. 받는 쪽이 늦으면 outbox가 차서 클라이언트까지 역압이 가고, 가득 찬 받는 쪽은 링크로 알려 보내는 쪽이 다시 보내지 않는다. 답(`--reply`)은 자기 보내기의 자리를 쓴다. 상태 4 MB를 준 노드는 부하 아래 상주 9.6–9.8 MiB에 멈춘다(예산 없이 30초에 45.9 MiB). 오래 붙든 스냅숏은 그때 상태 한 벌만 쥔다(전: 30초에 678 MiB) | [설계 013](docs/design/013-memory-budget.md), [104](docs/research/104-where-memory-goes.md) |
 | 표면과 메신저 | 사람을 위한 표면이 노드 안에서 돈다(`pure-serve --surface`): 마지막 저장의 스냅숏을 제자리에서 읽고, 친 키와 글자는 HTTP 요청과 같은 줄로 소유자에게 간다. Vega의 디스플레이·픽셀이 그 표면이다. 두 노드의 메신저(Vega `examples/messenger.aup`)는 서로에게 봉인·인증해 보내고, 한 줄이 상대 노드에 보이기까지 RAM 저장소에서 p50 0.79 ms·p99 1.1 ms, SD 카드에서 p50 3.5 ms(꼬리는 SD의 동기화) | [설계 010](docs/design/010-surfaces.md), [089](docs/research/089-messenger.md) |
 | 표 크기의 상태 | 목록이 영속 B+트리다(변경·키 탐색·저장본 위치 O(log n), 스냅숏 O(1), 1,600만 항목, 런타임 상태 1 GiB). pgbench의 TPC-B 같은 이체(세 표의 행과 이력, 한 트랜잭션)가 10만 계좌에서 RAM 24.5k/s(전: 3만 계좌 3.2k/s), SD 카드 내구 1,339/s(SQLite WAL FULL 84–153/s) | [090](docs/research/090-tables.md) |
-| 일반 트랜잭션 | TPC-C의 다섯 트랜잭션을 aup 앱 하나로 쓴다(여러 표 읽기·쓰기, 조각 훑기, 중복 없는 셈, 실패하면 통째 되돌림). 같은 입력에서 SQLite와 아홉 표의 모든 행이 같다(창고 하나와 넷). RAM 초당 36,567건(W=4 32,765; 조율한 SQLite 10,357, 트랜잭션당 CPU 46–54 µs, HTTP·JSON 포함), SD 카드 내구 4,980건(W=4 4,590). SQLite도 카드에 맞게 조율하고 묶어 커밋하면 739건(W=4 426)이다. 남은 차이는 거래당 쓰는 바이트다(SQLite는 페이지째 써서 8–18배) | [092](docs/research/092-tpcc.md), [106](docs/research/106-tpcc-conditions-first.md) |
+| 일반 트랜잭션 | TPC-C의 다섯 트랜잭션을 aup 앱 하나로 쓴다(여러 표 읽기·쓰기, 조각 훑기, 중복 없는 셈, 실패하면 통째 되돌림). 같은 입력에서 SQLite와 아홉 표의 모든 행이 같다(창고 하나와 넷). RAM 초당 40,976건(W=4 35,838; 조율한 SQLite 10,164, 트랜잭션당 CPU 43–50 µs, HTTP·JSON 포함), SD 카드 내구 4,980건(W=4 4,590). SQLite도 카드에 맞게 조율하고 묶어 커밋하면 739건(W=4 426)이다. 남은 차이는 거래당 쓰는 바이트다(SQLite는 페이지째 써서 8–18배) | [092](docs/research/092-tpcc.md), [106](docs/research/106-tpcc-conditions-first.md), [107](docs/research/107-snapshot-nodes-reused.md) |
 | 질의 | 질의는 앱의 상태 위에 보기를 더한 모듈이다(`aup query`, `PUT·GET /queries/이름`). 검증한 뒤 스냅숏에서 돌고, 열 안의 fold가 그 행을 읽는다(상관 부질의). 잎이 항목을 필드별로 들고, fold와 필터는 잎 하나씩 돌며(결함이 날 잎만 항목별로), 열 안의 그룹·순위 fold는 목록을 한 번 지나 모든 행에 답한다. 10만 계좌에서 지점별 합계 4.9 ms(SQLite 45, 인덱스를 주면 14.3), 조인 0.48 ms(1.47), 자기 조인 순위 6.8 ms(2,840, 인덱스를 주면 7.6). Pure에는 인덱스 선언이 없다 | [091](docs/research/091-queries.md) |
 
 키로 나눈 소유자와 저장을 넘길 스레드는 하지 않기로 했다. 이 장치는 동기화를 한 줄로 세워, 나누면 쓰기가 23% 줄고 넘겨도
 기기의 일은 줄지 않는다([084](docs/research/084-parallel-syncs.md)). 다만 동기화가 공짜인 RAM에서 TPC-C는 소유자 하나가
-병목이다(코어의 94%, 터미널을 늘려도 그대로). 그 시간의 3분의 1은 스냅숏이 공유한 노드를 복사하는 데 간다. 덜 복사하는 길과
-키로 나눈 소유자를 다음 설계로 함께 본다([106](docs/research/106-tpcc-conditions-first.md)). 대신 압축한 파일이 한 주기의 0을 미리 가져 커밋이 새
+병목이다(코어의 94%, 터미널을 늘려도 그대로, [106](docs/research/106-tpcc-conditions-first.md)). 그 시간의 3분의 1이
+스냅숏이 공유한 노드를 복사하고 놓는 데 갔고, 대부분 할당이었다. 스냅숏이 놓은 노드를 목록이 다시 쓰게 해 17%로 줄였다(처리량
++9%, 상주 −10%, [107](docs/research/107-snapshot-nodes-reused.md)). 남은 가장 큰 몫은 항목 찾기다. 키로 나눈 소유자는 그다음에 본다. 대신 압축한 파일이 한 주기의 0을 미리 가져 커밋이 새
 블록을 받지 않는다(저장소 커밋 +21%, 저널 커밋 −59%, [085](docs/research/085-cycle-sized-files.md)).
 
 남은 것: macOS 검증, `bool`·`i64`, 압축을 없애는 제자리 재사용 저장소(085 다음), 응답을 기다리는 출력의 묶음 전달(083), 앱
diff --git a/README.md b/README.md
index 0d93d9a..a68e4d4 100644
--- a/README.md
+++ b/README.md
@@ -17,11 +17,11 @@ their own (`aup query`), verified when registered and shown from snapshots. Fold
 fold in a table's column is answered for every row from one pass over its list, so on pgbench's tables of 100,000
 accounts a group-by, a join and a correlated rank run 3–420x faster than on SQLite, and faster than SQLite given a
 DBA's indexes but for one count, with no index declared. TPC-C's five transactions, written as one aup app, leave
-SQLite's state row for row from the same inputs, with one warehouse or four, and run 3.2–3.5x faster than a tuned
-SQLite in RAM (36,567 against 10,357 a second, HTTP and JSON included) and 4–11x faster on an SD card than SQLite
+SQLite's state row for row from the same inputs, with one warehouse or four, and run 3.5–4x faster than a tuned
+SQLite in RAM (40,976 against 10,164 a second, HTTP and JSON included) and 4–11x faster on an SD card than SQLite
 tuned for the card and committing in groups as Pure does, both answering once the commit is on the device: SQLite
 writes whole pages, 8–18x the bytes a transaction ([092](docs/research/092-tpcc.md),
-[106](docs/research/106-tpcc-conditions-first.md)). Measurements against axum and drogon on a Raspberry Pi 5
+[106](docs/research/106-tpcc-conditions-first.md), [107](docs/research/107-snapshot-nodes-reused.md)). Measurements against axum and drogon on a Raspberry Pi 5
 are in [075](docs/research/075-http-host-against-axum.md), [077](docs/research/077-apps-as-http-services.md),
 [080](docs/research/080-snapshot-reads.md), [081](docs/research/081-tail-records.md),
 [082](docs/research/082-json-in-place.md), [083](docs/research/083-delivery-over-http.md),
diff --git a/docs/research/106-tpcc-conditions-first.md b/docs/research/106-tpcc-conditions-first.md
index 919bcb4..d78079c 100644
--- a/docs/research/106-tpcc-conditions-first.md
+++ b/docs/research/106-tpcc-conditions-first.md
@@ -215,3 +215,4 @@ Pure의 값은 Pure의 실행이 모두 끝난 뒤다. 상태는 거의 모두 �
 
 다음은 **소유자의 시간**이다. 설계 노트에서 두 길을 함께 다룬다. 스냅숏이 공유한 잎을 고칠 때 덜 복사하는 길(모든 앱에
 듣는다)과, 키로 나눈 소유자가 한 저장소의 그룹 커밋을 함께 쓰는 길(코어를 더 쓴다)이다. 덜 복사하는 쪽을 먼저 잰다.
+그 첫걸음은 [107](107-snapshot-nodes-reused.md)이다. 복사의 몫 대부분이 할당이었고, 스냅숏이 놓은 노드를 되써 없앴다.