>>675-676の結果を考察してみる。
※あくまでも想像にすぎません

・【処理速度は　イベントの挿入 > 指定ラベルに飛ぶ】
ラベル処理は「イベント先頭からシークして、ラベルが存在したらジャンプ」というものになっているらしい。
ラベル名にも特殊文字を使えるため、ラベルジャンプコマンドを実行する段階にならないとジャンプ先が分からないのが原因か。
数千行のイベントになるとシーク量が多くなるため遅くなるということになるだろう
イベント挿入による呼び出しも、番号による場合は問題ないが、イベント名で呼び出す場合はやはりシークの必要性から遅くなる可能性もある

・【チェックをつける項目は基本処理速度が遅いが、ピクチャ関連は連番の方が速い】
連番による処理速度の違いは、コマンドの種類の違いではなく、内部処理量の問題だと思われる。
おそらく、連番で処理する場合は、コマンド呼び出しにオーバーヘッドがあるため、数個の変数操作だと遅くなる。逆に、cself[10]〜cself[99] = 0などにすれば代入命令90個書くより速いだろう。
ピクチャコマンドは一枚でも処理する量が多いため、少ない枚数でも違いが実感できるのではないだろうか。

・【注釈は1命令】
これはその通り。デバッグコマンド、チェックポイントも同様。
特にループ内にコメントを放り込むのはなるべく避けたほうがいい。
イベントコードコピーができるようになったので、正規表現が使えるテキストエディタで
^\[103\].*
を削除すると捗るかも。

・【コモンのデータ数は処理速度に関係しない?】
おそらく、起動条件のあるイベントだけチェックテーブルに放り込んでチェックしているため、起動条件のないイベントはいくら多くてもメモリの許す限りは処理速度には影響がない。
20M程度のファイルサイズで固まるのは、読み込みのオーバーヘッドが大きくてビジー状態になっただけなのか、何かしらの致命的なエラーによりデッドロック状態になったのかは不明。
条件付きの並列イベントは、増やせば増やすほど（たとえ実行していなくても）処理速度に影響が出るはず。
自動実行イベントは、一つが実行されていれば他はチェックされない（と思われる）ので、処理速度に対する影響は小さいのではないだろうか