測定環境
このページの数値はすべて、開発に使っている1台のノートPCで測定しました。一般的な内蔵グラフィックスの構成です。Windows版はまだここで測定しておらず、macOS版は開発中です。結果が出たら追加します。
| 端末 | OS | 画面 | 備考 |
|---|---|---|---|
| ノートPC、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がエディターへ描画を要求した回数を数えます。
| プラットフォーム | 10秒間のフレーム数 | 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のファイルを開き、5回計ります。メモリは、文書のレイアウトが終わってアプリがアイドルに入ったあとに/procから読んだPSSから、空の文書で計った同じ値を引いたものです。文書自体がこちらに課す費用で、70 MBのうち9.4 MBです。残りはこの機械のすべてのGTK4アプリが払うツールキットとGPUの床で、ドライバによって動きます。だから公表するのはそのうちの自分たちの分です。 バイナリは6.1 MBです。ファーストペイントはエディタ自身のフレームカウンタから読みますが、それは私たちのdevビルドにしかないので、他の3つは推測ではなく—にしています。
同じ端末、同じ文書
Typora、Obsidian、MarkTextを、同じ100 KBの文書で、それぞれのインライン編集画面（TyporaはWYSIWYG、Obsidianはライブプレビュー、MarkText）で、上の機械で、私たちの数字と同じ実行として開きました。メモリは文書のレイアウトが終わってアプリがアイドルに入ったあとのプロセスツリー全体のPSS、アイドルCPUはウィンドウにフォーカスを置き入力なしで30秒間のツリーのCPU、打鍵CPUは人の速さで150 msに1文字ずつ約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です。一方3つのElectronエディタは1.1〜1.6 %、毎秒29〜75回で座っています。2つ目は打鍵。コアの何分の一か対3分の1〜3分の2です。3つ目はメモリ。プロセス1つ対6〜9、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を1回。このページの数字は、私たちのものも他のエディタのものも、すべてその1回の実行から出ています。リリースごとに計り直します。