ベンチマーク

測定環境

このページの数値はすべて、開発に使っている1台のノートPCで測定しました。一般的な内蔵グラフィックスの構成です。macOS版とWindows版は開発中で、完成後に結果を追加します。

端末	OS	画面	備考
ノートPC、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がエディターへ描画を要求した回数を数えます。

プラットフォーム	10秒間のフレーム数	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 / 最大0.48 ms、後者はp50 2.6 / p95 9.7 / 最大12.7 msでした。下記の基準試験より古いコミットであるM3ビルドを使い、2026-09-02に測定しました。入力試験の結果はまだresultsディレクトリにないため、信頼する前に再実行が必要です。画面自体の応答時間は含まず、測定もしていません。

コールドスタート

主張：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は本当に待機状態になると処理を抑えるため、待機時の列でmoteとの差が出るのはObsidianとMarkTextであり、Typoraではありません。エンジンの差が表れるのはメモリと入力時の負荷です。プロセス数は1対6～8、キー入力あたりのCPU使用率は約10分の1です。ここでの78 MBが上記の69 MBより大きいのは、別セッションで測ったプロセスツリー全体の値だからです。GTKとMesaによる最低使用量は、セッションごとに十数MBほど変動します。

MarkTextは--no-sandbox付きで実行しました（このカーネルではサンドボックスが起動しないため）。Obsidianは、新規保管庫で中核プラグイン3つだけを有効にしました。生データ：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 %以上異なる場合は、お知らせください。差異を公開します。