文書が長くなっても入力が遅くならない理由

短いメモなら、どのエディターで書いても高速です。違いは文書が長くなったときに現れます。

キーを押すたびに文書全体を読み直して画面を再配置するなら、文書が長くなるほど入力も遅くなります。十行のメモでは問題なかったエディターが、二千行の設計文書ではもたつく理由です。

moteはこの問題を、あとで直すパフォーマンス上の課題とは考えませんでした。最初から守るべき設計原則として定めました。

編集するときは、変更された範囲だけを読み直して配置する。文書全体を読み直すのは、ファイルを開くときだけにする。

変更された箇所だけを読み直します

Markdownでは、前の行が後ろの行の意味を変えることがあります。文書の上部でコードブロックを開けば、それより下の内容がすべてコードになることがあり、同じ文でもリストや引用文の中では異なるものとして解釈されます。

そこでmoteは、それより前の影響が確実に終わる「安全地点」を記憶しておきます。編集が発生すると、近くの安全地点から読み始め、内容が再び安定した瞬間に止めます。

それより後ろのブロックは読み直しません。行が増減した場合は、位置だけを移動します。コストが文書全体ではなく、実際に変更された範囲に比例するようにしたのです。

パーサーはCommonMarkの行単位アルゴリズムに従い、652件の仕様テストをすべて通過しています。しかし、増分処理はひそかに間違いやすいものです。そこでランダムな文書にランダムな編集を3,600回適用したあと、毎回、文書全体を読み直した結果と比較します。

この検査は、実際のバグも見つけました。安全地点と編集した行が正確に重なる場合でした。

パフォーマンス原則は検査で守ります

目標は、キーを押してからコアの処理が終わるまでをp95で4msにすることです。この時間を超えた場合は、改善課題ではなくバグとして扱います。

ルールを文書に書いておくだけでもありません。自動検査によって、全体の再解析がファイルを開くときにだけ使われているかを確認します。アイドル状態で繰り返されるタイマーやフレーム処理も防ぎます。

パフォーマンスも、人間が目で見て判断することはありません。ハーネスが実際の画面にキー入力を行い、処理時間の分布を測定します。平均値や中央値ではなく、p95を見ます。ユーザーを苛立たせるのは普段の速度よりも、ときどき発生する長い遅延だからです。

測定には、常に同じ固定文書を使います。

画面も必要な分だけ変更します

パーサーを増分処理に変えるだけでは十分ではありませんでした。

コードブロックのシンタックスハイライトは、編集のたびにすべてのブロックを再処理していました。編集の大きさに関係なく、文書が長いほど遅くなる最後の処理でした。

現在は、変更していないブロックのシンタックスハイライトをそのまま再利用しています。編集箇所より後ろのブロックは、行数が変化した分だけ位置を移動します。

画面外のブロックはレイアウトしません。読み直す範囲と再描画する範囲の両方を減らさなければ、長い文書でも速度を維持できないからです。

例外もあります

文書全体を再処理しなければならない場合があります。

ファイルを開くときや、改行形式が変わるときです。リンク参照定義を修正すると、文書内のどこにあるリンクでも変わる可能性があるため、画面の更新範囲も文書全体に広げます。

コアが高速でも、画面では次のフレームを待つ時間が必要です。60Hzの画面であれば、フレーム間隔そのものが限界になります。そのため、コアの処理時間と実際に画面へ表示されるまでの時間を別々に測定し、二つの数値を同じ軸には載せません。表紙の二本の線が異なる理由です。

高速なエディターとは、すべての処理を速く行うエディターではありません。

しなくてもよい処理をしないエディターです。