벤치마크 — mote

측정 환경

이 페이지의 모든 수치는 앱을 개발하는 노트북 1대에서 측정했어요. 내장 그래픽을 사용하는 일반적인 구성이에요. macOS와 Windows 버전은 개발 중이에요. 완성되면 결과를 추가할게요.

기기	OS	디스플레이	비고
노트북, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2)	Ubuntu 24.04, X11의 GNOME	2560×1440 @ 60 Hz	릴리스 빌드, 커밋 `04cf7dc`

테스트 문서: tools/perf/fixtures/doc100k.md (100 KB, 874줄) · 3회 실행의 중앙값 · 포인터는 창 밖에 배치 · 실제 세션 버스.

유휴 프레임

측정값: 아무 변화가 없으면 mote는 아무것도 그리지 않아요. 라이브 보기에서 문서를 열고 편집기 포커스를 해제해 캐럿이 깜박이지 않도록 했어요. 10초 동안 입력하지 않은 상태에서 실행 후 t = 5–15 s 사이의 편집기 스냅샷 수를 셌어요. GTK가 편집기에 그리기를 요청할 때마다 1회로 계산했어요.

플랫폼	10 s 동안의 프레임	평균 CPU	측정 방법
Linux	`0`	0.0%	`tools/perf/gate.sh`로 편집기 스냅샷 수 측정

캐럿 깜박임을 켜면 캐럿이 깜박일 때마다 편집기를 1회 다시 그려요. 창에 포커스가 있을 때의 기본 동작이에요. 바뀌는 것은 캐럿뿐이며 포커스가 창을 벗어나면 바로 멈춰요. 앱이 유지하는 반복 타이머는 이 깜박임뿐이에요. 유휴 상태에서는 다른 작업이 반복되지 않아요.

입력 지연 시간

측정값: 키 입력부터 픽셀까지 95백분위에서 9.7 ms예요. 키 입력 → 처리: p95 0.29 ms. 키 입력 → 픽셀(vsync 포함): p95 9.7 ms. 100 KB 문서를 라이브 보기로 열고 tools/perf/typing.sh를 사용해 프로세스 내부에서 측정했어요.

처리는 입력 이벤트가 문서를 갱신하고 영향을 받은 레이아웃을 무효화한 시점을 뜻해요. 픽셀은 다음 스냅샷이 끝난 시점이에요. 프레임 클록을 기다리므로 vsync의 영향을 받아요. 60 Hz에서는 16.7 ms예요. 300회가 넘는 키 입력에서 처리 시간은 p50 0.01 / p95 0.29 / max 0.48 ms였어요. 픽셀까지 걸린 시간은 p50 2.6 / p95 9.7 / max 12.7 ms였어요. 아래 게이트 실행보다 앞선 커밋인 M3 빌드에서 2026-09-02에 측정했어요. 입력 실행 결과는 아직 결과 디렉터리에 없어요. 신뢰하기 전에 다시 실행해야 해요. 디스플레이 자체의 응답 시간은 포함하지 않았고 따로 측정하지 않았어요.

콜드 스타트

측정값: 100 KB 파일을 열면서 실행하면 창이 나타날 때까지 211 ms가 걸려요. 콜드는 새 프로세스에서 파일을 함께 여는 조건이에요. 미리 준비한 항목은 없고 페이지 캐시는 그대로 뒀어요. exec에서 측정을 시작해 창이 매핑될 때 끝냈어요. 첫 그리기는 같은 시계로 편집기가 문서의 첫 스냅샷을 끝낼 때까지 측정했어요.

플랫폼	exec → 창	첫 그리기	바이너리 크기	불러온 뒤 RSS (PSS)
Linux	211 ms	231 ms	3.1 MB	69 MB

측정 방법: tools/perf/gate.sh, 콜드 = 새 프로세스, 실행할 때 100 KB 파일 열기. 문서 레이아웃이 끝나고 앱이 유휴 상태가 된 15초 뒤 /proc에서 PSS를 읽었어요.

같은 기기, 같은 문서

Typora, Obsidian, MarkText에서 같은 100 KB 문서를 인라인 편집 보기로 열었어요. Typora는 WYSIWYG, Obsidian은 Live Preview, MarkText는 기본 보기를 사용했어요. 위 기기에서 같은 스크립트로 측정했어요. 메모리는 실행 12초 뒤 전체 프로세스 트리의 PSS예요. 유휴 CPU는 창에 포커스를 둔 채 입력 없이 5–10초 사이에 사용한 프로세스 트리 CPU예요. 입력 CPU는 약 150자를 30 ms마다 1자씩 입력할 때 사용한 프로세스 트리 CPU예요. 편집기마다 준비 실행 1회를 제외하고 7회 실행한 평균이에요.

편집기	버전	PSS	유휴 CPU	입력 CPU	프로세스
mote	출시 전, 커밋 `b17c3bf`	78 MB	0.0%	10.9%	1
Typora	1.14.9	453 MB	0.1%	102.6%	8
Obsidian	1.12.7	361 MB	0.8%	152.5%	7
MarkText	0.19.1	416 MB	0.6%	135.8%	6

Typora의 유휴 CPU는 mote만큼 낮아요. 이 점도 그대로 밝혀요. Chromium은 완전한 유휴 상태에서 작업을 줄여요. 따라서 유휴 CPU 수치는 mote와 Obsidian, MarkText의 차이를 보여 주지만 Typora와의 차이는 보여 주지 않아요. 엔진의 차이는 메모리와 입력 비용에서 드러나요. 프로세스 수는 1개와 6~8개로 갈리고 키 입력당 CPU는 약 10분의 1이에요. 여기의 78 MB가 위의 69 MB보다 큰 이유는 다른 세션에서 전체 프로세스 트리를 측정했기 때문이에요. GTK와 Mesa의 기본 사용량은 세션마다 10여 메가바이트씩 달라져요.

MarkText는 --no-sandbox로 실행했어요. 이 커널에서는 샌드박스가 시작되지 않아요. Obsidian은 코어 플러그인 3개만 있는 새 vault에서 실행했어요. 원시 데이터: experiments/2026-09-03-apps-idle-startup/raw.csv.

직접 재현하기

측정 도구, 말뭉치, 원시 CSV, 결과 JSON은 베타와 함께 GitHub의 공개 벤치마크 저장소에 게시할 예정이에요. tools/perf/gate.sh <binary> :1 3는 게이트를 실행하고 tools/perf/bench-apps.sh는 비교를 실행해요. 측정값이 저희 결과와 15 % 넘게 다르면 알려 주세요. 차이도 공개할게요.