Show the new layout costs nothing, and keep code where it was

The benchmark runs an earlier pure-serve build in turn with the current one
(--baseline). Against the build before the move, linking through libpure.a
costs nothing: a one-command build with the library's object order has the
same size and the same CPU per request. What moved was code placement, so
the runtime links last again, as it did; the two orders now differ by less
than rounds of one build do (total -0.4%, page +1.2%, mixed -0.1%). The
binary is 5,008 B smaller: unused flow.c functions stay in the library, and
the linker's A53 erratum padding is gone.

1 files changed, 9 insertions, 0 deletions

diff --git a/docs/design/009-layout.md b/docs/design/009-layout.md
index 8cb9a78..17d6a48 100644
--- a/docs/design/009-layout.md
+++ b/docs/design/009-layout.md
@@ -54,6 +54,15 @@ GET, 입력이 POST)에는 어휘가 필요 없기 때문이다. 모듈 형식�
 `java.net`과 HTTP 서버를 담고 JavaFX를 따로 두는 것과 같은 선이다. `pure-ui`라는 이름은 UI가 런타임의 일부라는 뜻이
 되어, 런타임이 화면을 모른다는 분리와 어긋난다.
 
+## 비용
+
+같은 소스를 옮기기 전(`5239052`)처럼 한 명령으로 빌드한 것과 라이브러리로 링크한 것을 번갈아 쟀다(Pi 5, 점수판 앱,
+연결 스레드 3, 라운드 6번씩 3초, 요청당 CPU). 라이브러리라는 구조의 비용은 없다. 한 명령 빌드도 오브젝트 순서를 라이브러리
+빌드와 같게 하면 크기(228,041 B)와 효율이 같다(total +0.4%, page +0.2%). 남은 차이는 코드 배치다. `runtime.c`를 예전처럼
+마지막에 링크하면 예전 순서와 total −0.4%, page +1.2%, mixed −0.1%로 같은 빌드끼리의 라운드 차이(±1%) 안이다. 크기는
+5,008 B 줄었다. 쓰지 않는 `flow.c` 함수(516 B)를 라이브러리에서 끌어오지 않고, 예전 바이너리에 있던 링커의 Cortex-A53
+오류 회피 분기 자리(4 KiB 정렬 여백)가 없다. 벤치마크의 `--baseline`으로 다시 잴 수 있다.
+
 ## 확인
 
 최상위 `make check`(저장소와 앱 모델의 검사), `prototypes/connections`의 `make check`·`check-tree`·`check-core`, aup