측정 환경
이 페이지의 모든 수치는 mori를 개발하는 노트북 1대에서 측정했어요. 내장 그래픽을 쓰는 일반적인 구성이에요. Windows 버전은 아직 여기서 측정하지 않았고 macOS 버전은 개발 중이며, 결과가 생기면 추가해요.
| 기기 | OS | 디스플레이 | 비고 |
|---|---|---|---|
| 노트북, Intel i5-11300H, 23 GB, Iris Xe (Mesa 25.2) | Ubuntu 24.04, X11의 GNOME | 2560×1440 @ 180 Hz | 릴리스 빌드 1.0.0, 커밋 183cc22 |
테스트 문서: tools/perf/fixtures/doc100k.md (100 KB, 874줄) · 3회 실행의 중앙값 · 포인터는 창 밖에 배치 · 실제 세션 버스
대기 중 화면 갱신
측정 기준: 아무 변화가 없으면 mori는 화면을 갱신하지 않아요 라이브 보기에서 문서를 열고 편집기의 포커스를 해제해 캐럿이 깜박이지 않도록 했어요. 10초 동안 입력하지 않고 실행 후 t = 5–15 s 사이의 편집기 스냅샷 수를 셌어요. GTK가 편집기에 그리기를 요청할 때마다 1회로 계산했어요.
| 플랫폼 | 10 s 동안의 화면 갱신 | 평균 CPU | 측정 방법 |
|---|---|---|---|
| Linux | 0 | 0.0% | tools/perf/gate.sh로 편집기 스냅샷 수 측정 |
캐럿 깜박임을 켜면 캐럿이 깜박일 때마다 편집기를 1회 다시 그려요. 창에 포커스가 있을 때의 기본 동작이에요. 바뀌는 것은 캐럿뿐이며 포커스가 창을 벗어나면 바로 멈춰요. 앱이 유지하는 반복 타이머는 이 깜박임뿐이에요. 대기 중에는 다른 작업이 반복되지 않아요.
키 입력 반응
주장: 키 입력에서 픽셀까지 95번째 백분위 18.2 ms. tools/perf/index/e2e_latency.sh가 프로세스 밖에서 잽니다. XTest로 키를 넣고 캐럿 줄이 바뀔 때까지 화면을 폴링해요. 100 KB 문서, 라이브 화면, 2560×1440 · 180 Hz. 119타 기준 p50 14.1 · p95 18.2 · p99 19.1 · 최대 20.4 ms.
이 숫자에는 키와 픽셀 사이의 모든 것이 들어갑니다. 툴킷, 컴포지터, 그리고 다음 프레임까지의 대기까지요. 그 대기는 0에서 주사율 간격 사이에 아무 데나 떨어져서, 180 Hz면 최대 5.6 ms·평균 2.8 ms가 더해집니다. 그래서 같은 주사율에서 잰 다른 편집기하고만 나란히 놓을 수 있어요. 화면 자체의 응답 시간은 포함하지 않았습니다. 재지 않았으니까요.
첫 실행
주장: 아무것도 캐시되지 않은 상태에서 100 KB 파일을 연 채 실행부터 창까지 387 ms. 콜드는 새 프로세스에 페이지 캐시까지 비운 상태예요. 바이너리도, 라이브러리도, 파일도 전부 디스크에서 읽습니다. 캐시가 살아 있는 평소라면 같은 실행이 259 ms예요. 시계는 exec에서 시작해 창이 화면에 올라올 때 멈추고, 첫 페인트는 같은 시계를 편집기가 문서를 처음 그린 순간에 멈춘 값입니다.
| 편집기 | exec → 창 | 캐시가 있을 때 | 첫 그리기 | 프로세스 수 |
|---|---|---|---|---|
| mori | 387 ms | 259 ms | 377 ms | 1 |
| Typora | 814 ms | 511 ms | — | 9 |
| Obsidian | 2,975 ms | 2,862 ms | — | 7 |
| MarkText | 2,042 ms | 1,872 ms | — | 6 |
방법: tools/perf/run-index.sh, 콜드는 페이지 캐시를 비운 새 프로세스에서 100 KB 파일을 열고 다섯 번 잽니다. 메모리는 문서 배치가 끝나고 앱이 유휴로 들어간 뒤 /proc에서 읽은 PSS에서, 빈 문서로 잰 같은 값을 뺀 것이에요. 문서가 우리에게 물리는 비용이고, 70 MB 중 9.4 MB입니다. 나머지는 이 기계의 모든 GTK4 앱이 함께 내는 툴킷·GPU 바닥이고 드라이버에 따라 움직여요. 그래서 우리가 공개하는 값은 그중 우리 몫입니다. 바이너리는 6.1 MB입니다. 첫 그리기는 편집기 자신의 프레임 카운터에서 읽는데 그건 우리 dev 빌드에만 있어서, 나머지 셋은 추측 대신 —로 둡니다.
같은 기기, 같은 문서
Typora, Obsidian, MarkText를 같은 100 KB 문서로, 각자의 인라인 편집 화면(Typora는 WYSIWYG, Obsidian은 라이브 프리뷰, MarkText)에서, 위 기계에서, 우리 숫자와 같은 실행으로 열었습니다. 메모리는 문서 배치가 끝나고 앱이 유휴로 들어간 뒤 프로세스 트리 전체의 PSS, 유휴 CPU는 창에 포커스를 두고 입력 없이 30초 동안 트리의 CPU, 타이핑 CPU는 사람 속도로 150 ms에 한 글자씩 약 700자를 치는 동안 트리의 CPU예요.
| 편집기 | 버전 | PSS | 대기 중 CPU | 입력 중 CPU | 프로세스 수 |
|---|---|---|---|---|---|
| mori | 1.0.0, 커밋 183cc22 | 70 MB | 0.0% | 7.2% | 1 |
| Typora | 1.14.9 | 457 MB | 1.1% | 30.5% | 9 |
| Obsidian | 1.12.7 | 346 MB | 1.6% | 32.5% | 7 |
| MarkText | 0.20.0-rc.1 | 405 MB | 1.4% | 62.3% | 6 |
엔진이 처음 갈리는 자리는 유휴입니다. 창을 열어 두고 아무 일도 하지 않을 때 mori는 잴 수 있는 CPU를 쓰지 않고 웨이크업도 초당 0인 반면, Electron 편집기 셋은 1.1~1.6 %와 초당 29~75회에 앉아 있어요. 두 번째는 타이핑입니다. 코어의 몇 분의 일 대 3분의 1~3분의 2죠. 세 번째는 메모리예요. 프로세스 하나 대 여섯~아홉, 70 MB 대 346~457 MB.
MarkText는 --no-sandbox로 실행했습니다(이 커널에서는 샌드박스가 시작되지 않아요). Obsidian은 별도의 사용자 데이터 폴더에서 실행했습니다. 원자료: tools/perf/results/2026-09-09-linux-myasus-180hz.json.
직접 재현
하네스와 결과 파일은 저장소에 있고, 코퍼스와 원자료를 담은 공개 저장소는 준비 중이며 날짜는 아직 없습니다. tools/perf/run-index.sh가 모든 지표를 돌리고, tools/perf/check.sh가 결과를 예산에 비춰 검증해요. 재보신 숫자가 우리 것과 15 % 넘게 다르면 알려 주세요. 그 차이를 공개합니다.
마지막 실행: 2026-09-09, 커밋 183cc22에 대해 tools/perf/run-index.sh를 한 번. 이 페이지의 모든 숫자는 우리 것이든 다른 편집기 것이든 그 한 번의 실행에서 나왔습니다. 릴리스마다 다시 잽니다.