「軽い」と言う代わりに数字を公開する理由

マークダウンエディタは、よくこのように紹介されます。

速い。軽い。滑らかだ。

しかし、数字に条件が欠けていれば、形容詞と変わりません。アイドル時のCPUをいつ、どれくらいの時間測ったのか。起動時間をどこからどこまでとして計算したのか。条件の異なる数字は比較できないからです。

そこで、moteが公開する性能指標を8つに定めました。各指標には、測定方法と条件、除外対象、比較ルール、注意点、予算を記録しました。測定スクリプトも一つずつ紐づけました。

文書と結果、コードには、すべて同じ名前を使っています。数字がどこから出たのか、すぐに追跡できるようにするためです。

数字には条件が伴うべきです

moteは4つの原則を守ります。

すべての測定値について、値と単位、統計、サンプル数、生のサンプルをあわせて保存します。単位が欠けた結果は、検査段階で拒否します。

測っていない値は記載しません。測定できない場合は、理由とともに空欄にします。推定値で埋めることはしません。

比較は、同じマシンと同じセッションでのみ行います。別の日、別の機器で得られた数字を並べることはしません。

測定条件も数字とあわせて公開します。特にリフレッシュレートとCPUガバナーは必ず記載します。この条件が異なると、遅延時間と起動時間を正しく比較できません。

測定方法を新しく考案したわけではありません。

キー入力から画面が変わるまでの遅延は、Pavel FatinのTypometerが採用した方法そのものです。アプリの外部からキーを入力し、ピクセルが変化するまで確認します。起動時間はVS Codeのように段階別に分け、コールドスタートとウォームスタートを区別しました。

遅延はフレームワークの内部ではなく、エンドツーエンドで測るべきだという原則は、Dan Luuの記事から取り入れました。

同じ条件で直接比較しました

競合アプリの性能について、ほかで公開されている数字は引用しませんでした。同じノートパソコンで直接測定しました。

同じ100KBの文書を開き、同じスクリプトを使ってアプリごとに7回ずつ実行しました。すべてインライン編集画面を使用し、ポインターの位置も同じになるように揃えました。

プロセス全体のメモリ使用量は次のとおりでした。

• mote: 78MB
• Typora: 453MB
• Obsidian: 361MB
• MarkText: 416MB

タイピング中のCPU使用率は、1コア基準で10.9%、103%、152%、136%でした。プロセス数はそれぞれ1個、8個、7個、6個でした。

moteのメモリ使用量は4.6倍から5.8倍少ない結果でした。タイピング中に使用するCPUは9.4倍から14倍少ない結果でした。

メモリはRSSではなくPSSで計算しました。RSSでは、複数のプロセスが共有するメモリを重複して数えることがあります。PSSでは、共有メモリをプロセス数に応じて分割して計算します。システムモニターで表示される方式とも同じです。

不利な数字もそのまま残しました

アプリを開いたままにしただけの状態でのCPU使用率は、moteが0.0%、Typoraが0.1%、Obsidianが0.8%、MarkTextが0.6%でした。

Typoraもアイドル状態ではCPUをほとんど使用しませんでした。したがって、「開いたままにしても何もしない」という点を、Typoraより優れている点として掲げることはできません。

ウェブシェルは3.6%を使用し、むしろTyporaより悪い結果でした。

アプリ内部の繰り返しタイマーをなくすことは、依然として重要です。しかし、守るべき原則と競争上の優位性は別の問題です。

アイドルフレームについては、競合アプリと比較しませんでした。moteの目標は10秒間に0フレームですが、ほかのアプリには同じ方法で確認できるフレームカウンターがありません。

そのため、競合アプリの欄は空欄にしました。空欄は0ではありません。

比較できないなら比較しません

ファイルを開き、変更せずに保存したとき、元の内容がそのまま維持されるかどうかも確認します。

moteはCommonMarkの652個の例を検査します。リポジトリ内のすべての文書についても、開いて再び保存したあと、バイト単位で同一かどうかを確認します。一つでも異なれば、性能上の問題ではなくデータ損失のバグと見なします。

競合アプリの結果は記載しませんでした。保存の過程を同じ条件で自動化することが難しかったためです。

測定前にはマシンの状態も確認します。コンパイルが実行中の場合は、測定を開始しません。ブラウザについては、実際にCPUを多く使用している場合にのみ測定を止めます。ロードアベレージとCPUアイドル率、判断基準、測定時の値は、すべて結果に残します。

このルールは、失敗を経験したあとに生まれました。

CPUを多く使用しているブラウザを開いたまま起動時間を測ったところ、性能が悪化したように見えました。以前のコミットと現在のコミットを同じ負荷のもとで交互に測定してみると、原因はコードのリグレッションではなくマシンの負荷でした。

それ以来、起動時間は一つの絶対値だけを見て判断しません。

予算を超えるとマージできません

性能予算は、文書にだけ記載された目標ではありません。ビルドを通過するために守らなければならない基準です。

基準はhardとreportに分けます。

hardは、意思決定文書によって数値が定められた項目です。一つでも基準を超えると検査は失敗します。個別の例外承認もありません。

reportは、まだ根拠が不足しているか、プラットフォームの制約に大きく影響される項目です。値は記録しますが、ビルドを止めることはありません。

根拠の乏しい数字でビルドを止めると、人々は測定そのものを避けるようになります。そのため、確かな基準だけをゲートとして使用します。

測定スクリプトと元のCSV、結果のJSONは、リポジトリにまとめて保管します。同じ条件で同じスクリプトを実行すれば、表を再作成できます。測定ツールとテスト文書を公開ベンチマークリポジトリとして提供する準備も進めています。

良い数字だけを選ぶことは、公開ではありません。

何をどのように測ったのか、どのような条件だったのか、何を測れなかったのかまであわせて示すこと。それが、moteが数字を公開する方法です。