結論：並列処理が重いという事実は確認できず。
身も蓋もない結論になるが、調べた限りにおいて、並列処理は他のイベントと比較して重いという事実は確認されなかった。
確かに重たい処理を行えば、そのイベントを原因としてゲーム全体が重くなる可能性を秘めている。しかし、「並列処理を使った」というだけでは、重くなる現象は見られない。実際に重くなるかどうかは、イベントの内容次第ということになり、別にそれは「自動実行」でも「決定ボタン」でも起こりうることだろう。
実験手順
１．MVのバージョン 1.6.1 の空のプロジェクトを用意する。
２．大きさ 250×250 のエリアマップを用意する。適当な地面を敷き詰めておく。
３．主人公の座標の近くに、500個のイベントを敷き詰める。正確な測定のため、イベントの処理内容は空とし、条件も設けないデフォルトのままとする。
４．イベントのトリガーは「決定ボタン」「プレイヤーから接触」「イベントから接触」「自動実行」「並列処理」のいずれかで統一する。5パターンそれぞれについて、ゲーム内の処理時間を記録する。
５．比較のため、「イベント未配置」のケースも調べる。これは、イベントが1個も無い場合のゲーム内の処理時間を割り出すことで、イベントの処理にかかる時間と、それ以外の処理にかかる時間を分別するためである。
６．ゲーム内の処理時間の計測には、ゲーム内で F2 キーを押して表示される（FPSMeter による）ミリ秒表示の値を使用する。通常、F2 キーを2回押すと表示される。また、このミリ秒の表示値は「SA FPSMeter Customizer」プラグインにより、小数点以下1桁まで表示されるように拡張されている。
７．計測は、イベントのトリガーの種類ごとに、50回ずつ行う。
８．計測結果は統計処理を通し、5%の有意差検定により、違いがあるかどうかを判定する。
９．通常のCPU速度では負荷が軽すぎて、FPSMeter の表示値が1ミリ秒未満となってしまうため、プロセッサの速度を 20％に固定してから計測した。このとき、CPUの周波数は 0.8 GHz に固定される。
実験に使用したマップ
計測時のスクリーンショット
すべての計測の記録のため、スクリーンショットを取得した。スクリーンショットの数は、6パターン×50回＝300枚となった。
撮影されたミリ秒の表示値を読み取り、テキストファイルに記録して、統計処理を行った。
判定結果
イベント未配置 平均 1.34 ミリ秒
イベントを配置した場合と比較して、有意な差がある。イベントを配置したことにより、ゲーム内の処理時間が増加したことは確実だ。
決定ボタン 平均 3.76 ミリ秒
プレイヤーから接触 平均 4.20 ミリ秒
イベントから接触 平均 3.89 ミリ秒
自動実行 平均 4.06 ミリ秒
並列処理 平均 4.13 ミリ秒
これらは他のトリガーでの結果と比較して、有意な差は無い。イベントのトリガーの違いによって、ゲーム内の処理時間に差が生じることはない。
補足
主人公の座標を、イベントの配置場所から最も遠い場所にセットした場合でも、結果は同様であった。イベントから距離が遠いことによる負荷軽減は、今回の実験には影響を与えなかったようだ。
並列処理が重いと言われる理由
並列処理は、設定された条件を満たせば、必ず何度でもイベントの内容が実行されるため、他のトリガーを利用したケースに比べて、イベントの実行回数は多くなりがちだ。
そのため、並列処理のイベントの内容が処理時間のかかるものであった場合に、実行回数との相乗効果により、結果としてMVの全体の重さに影響を与えやすいのではなかろうか？
逆に考えると、処理時間が短くて済む軽い処理を記述する限りにおいては、並列処理を多用しても何ら問題はないということになる。今回は、考えうる限り最も軽いイベントをマップ内に500個配置した。その結果から分かったのは、単に500個を配置するというだけでは、MVのゲーム画面は軽いままであることが見て取れると思う。
MVのイベント設置による重さは、イベントのトリガーの種類やイベントの総数は関係が無く、イベントの内容に依存していると考えて良いだろう。
実際、並列処理イベントを500個配置しても、それらに要するゲーム内の処理時間は 4ミリ秒程度（イベント未設定の結果を差し引くと、3ミリ秒程度）であり、この値ならば余裕を持って 60FPSを維持できる。（MVのゲームの重さの正体は？ を参照）
また、先に述べたとおり、CPUの周波数を 0.8 GHzに下げている状態での実験であることを思い出してほしい。CPUの周波数が 0.8 GHzを上回る環境ならば、処理時間が短くなることが期待できる（あなたの所有するPCは、省電力機能が効きすぎていない限り、1GHz以上で動作しているに違いない！）。