1 files changed, 84 insertions, 0 deletions
diff --git a/docs/design/020-computing-faster.md b/docs/design/020-computing-faster.md
new file mode 100644
index 0000000..b839e83
--- /dev/null
+++ b/docs/design/020-computing-faster.md
@@ -0,0 +1,84 @@
+# 020 — 계산을 빠르게, 긴 보기를 연결 스레드 밖에서
+
+작성일: 2026-10-04. 상태: 설계와 착수 기준(구현 전).
+[018](018-lifetimes-and-computation.md)이 계산을 들였지만 그 값이 컸다: BFS(노드 10만, 간선 100만) 한 이벤트가 396 ms로 CPython과
+비슷하고 C의 44배였다([118](../research/118-computing-in-one-event.md)). 계산하는 보기는 연결 스레드에서 돌아 그동안 그 스레드의 다른
+연결을 기다리게 했다([119](../research/119-views-that-compute.md)).
+
+## 문제: 재어 본 것
+
+**어디에 가는가.** 코어만으로 BFS를 돌려(`036-faster-loops/bfs-run.c`, 호스트 없이, 394 ms) gprof로 본 몫:
+
+| 함수 | 몫 | 무엇 |
+|---|---:|---|
+| `pure_list_seek` | 61% | 키로 찾기: 간선마다 `seen.has`, 노드마다 `seen.add`, `seen[q.node]`, 간선 조각의 두 경계. BFS 한 번에 약 140만 번, 한 번에 약 183 ns |
+| `run` | 13% | 실행기 자신 |
+| `pure_list_get` + `descend` | 17% | 위치로 항목 읽기: 걷는 항목의 필드(`e.to`), 찾은 항목(`seen[…]`)마다 뿌리부터 다시 내려간다 |
+
+키로 찾기 한 번이 183 ns인 것은 명령이 아니라 메모리다. 리스트는 영속 B+트리(가지 32)라 10만 항목이면 3–4단을 내려가고, 단마다
+캐시에 없는 노드를 읽는다. C의 BFS는 노드 번호로 배열을 바로 읽는다(간선 하나에 미스 하나).
+
+**긴 보기.** 연결 스레드를 코어보다 많이(8) 두면 보기가 나란히 돌지만(초당 46번, 스레드 셋에서는 연결이 같은 스레드에 떨어지면 22번),
+쓰기의 최대 지연은 그대로 100–130 ms다. 보기를 계산하는 스레드에 붙은 쓰기 연결은 계산이 끝날 때까지 기다린다. 스레드 수로는 꼬리가
+풀리지 않는다.
+
+## 원칙
+
+- **뜻은 그대로, 길만 빠르게.** 키 있는 리스트는 여전히 키 순서의 리스트이고 인덱스는 위치다. 바꾸는 것은 같은 답에 이르는 길이다.
+- **잰 것을 고친다.** 위의 표가 순서를 정한다.
+- **연결 스레드는 연결을 읽고 쓴다.** 오래 걸릴 수 있는 계산(본문이 있는 보기)은 보기의 스레드가 한다.
+
+## 모양
+
+### 1. 키로 찾기를 싸게
+
+- **이벤트의 리스트의 소속 표.** 수로 키를 둔 이벤트의 리스트(018: `let seen: list of Seen by node`, 메시지의 행은 키가 없다)는 B+트리
+  옆에 키의 해시 집합을 가진다(열린 주소, 선형 탐사, 지우면 뒤를 당긴다). `has`는 그것만 본다(미스 하나). 넣기와 지우기와 비우기가
+  함께 고친다. 이벤트의 리스트는 되돌리기도 저장도 스냅숏의 나눔도 없으니(018) 그 셋을 따라 고칠 일이 없다. 그 바이트는 이벤트가
+  쥔 것으로 센다(018의 몫).
+- **손가락.** 리스트는 마지막으로 내려간 잎과 그 잎의 첫 위치, 그때의 판을 기억한다. 위치로 읽는 것(`pure_list_get`)이 그 잎 안이면
+  내려가지 않는다. 키로 찾은 뒤 그 항목을 읽는 것(`seen[x].depth`), 걷기가 다음 항목을 읽는 것, 큐를 차례로 읽는 것(`queue.first +
+  i`)이 그렇다. 판이 바뀌면(넣기, 지우기, 바꾸기) 잊는다. 저장되는 리스트와 스냅숏의 사본도 같이 쓴다(읽는 쪽마다 제 사본이다).
+
+### 2. 긴 보기를 연결 스레드 밖에서
+
+- `pure-serve`는 보기의 스레드를 둔다(`--view-workers N`, 기본은 CPU 수). 본문이 있는 보기(018: 로드할 때 적힌다)의 `GET`은 연결
+  스레드가 보기의 스레드에 넘기고, 보기의 스레드가 자기 읽는 쪽에서 최신 스냅숏으로 계산해 답을 연결 스레드에 돌려준다(소유자가 답을
+  돌려주는 길과 같다: eventfd). 연결 스레드는 그동안 다른 연결을 읽고 쓴다.
+- 미는 보기(019)도 같다: 본문이 있는 보기의 무리는 미는 일에서 계산을 넘기고, 값이 돌아오면 보낸다. 그동안 무리의 구독자가 다
+  떠나도 무리는 값이 돌아올 때까지 남는다.
+- 본문이 없는 보기(식 하나)는 지금처럼 연결 스레드가 계산한다(가장 흔하고 짧은 길을 그대로 둔다).
+- 넘긴 일이 `--queue`만큼 쌓이면 503 `busy`다.
+
+## 단계
+
+1. 키로 찾기(소속 표, 손가락).
+2. 긴 보기를 보기의 스레드로(요청과 미는 일).
+
+## 1단계의 착수 기준
+
+- **바꿀 결정:** 이벤트의 리스트에 소속 표를, 모든 리스트에 손가락을 둘지.
+- **최소 확인:** test-module에서 소속 표와 손가락을 가진 리스트가, 같은 무작위 넣기·지우기·찾기·읽기·비우기 열에서 그것 없는 리스트와
+  매 단계 같은 답을 낸다(지우기가 탐사의 사슬 가운데를 빼는 경우 포함, 스냅숏의 사본 포함). aup의 `computing`(BFS, DFS, 다익스트라,
+  배낭)과 Pure, aup, Vega의 모든 검사가 초록이다.
+- **통과 조건**(RAM의 Pi 5):
+  - BFS(노드 10만, 간선 100만, `bfs-run`) 한 번의 중앙값이 200 ms 이하다(394 ms의 절반 남짓). HTTP로 잰 033의 `bfs.py`도 밝힌다.
+  - 지금의 앱: TPC-C와 은행 질의를 전과 후 번갈아 여섯 쌍 재서 중앙값이 3% 넘게 느려지지 않는다. 손가락은 모든 리스트의 읽기를
+    바꾸므로 은행 질의의 명령 수를 밝힌다(늘면 1% 안이어야 한다).
+
+## 2단계의 착수 기준
+
+- **바꿀 결정:** 본문이 있는 보기를 보기의 스레드에서 계산할지.
+- **최소 확인:** 019와 018의 검사(`server_view_bodies`, `server_push`)가 그대로 초록이다. 64연결이 동시에 묻는 `distance`가 모두 모델과
+  같다. 보기의 스레드에서 계산하는 동안 앱의 모듈을 바꾸거나 앱을 멈춰도 답이 섞이지 않는다(옛 모듈의 답이거나 503).
+- **통과 조건**(RAM의 Pi 5, 034의 `views.py`):
+  - 꼬리: 연결 둘이 BFS 보기를 쉬지 않고 묻는 동안 쓰기의 최대 지연 중앙값이, 같은 코어에서 다른 프로세스가 그 보기를 계산할 때
+    (apart)의 2배 이하다(지금 100–190 ms 대 6–9 ms).
+  - 나란히: 연결 스레드 하나(`--threads 1`)에서도 연결 둘이 묻는 BFS 보기의 처리량이 연결 하나일 때의 1.8배 이상이다(지금 1.0배).
+  - 짧은 보기: 본문 없는 보기(`total`)의 읽기 처리량(64연결)이 전과 후 번갈아 여섯 쌍에서 3% 넘게 줄지 않는다.
+
+## 하지 않는 것
+
+- 키 있는 리스트를 해시 맵으로 바꾸기. 키 순서의 걷기와 위치로서의 인덱스가 언어의 뜻이다.
+- 저장되는 리스트의 소속 표. 되돌리기, 저장, 스냅숏의 나눔을 함께 고쳐야 한다. 이벤트의 리스트로 효과를 본 뒤에 잰다.
+- JIT. 실행기 자신은 13%다.