プラグインの内部の JavaScirpt についての Memo（小話）です。
実験結果などは何一つ載っていないため、あなたが物凄く暇を持て余しているのでなければ、小話のたぐいは読み飛ばしが安定でしょう。
これは、筆者が本当はプログラマでも何でもなく、どこまでもゲーマーだったというお話――
突然ですが、あなたはどちらがお好きですか？
A. 実行速度は遅いけれど、見通しの良いコード
B. 見通しは悪いけれど、実行速度の速いコード
A の例
Game_Map.prototype.events = function() {
return this._events.filter(function(event) {
return !!event;
});
};
B の例
Game_Map.prototype.events = function() {
var filtered = [];
for (var i = 0; i < this._events.length; i++) {
var event = this._events[i];
if (!!event) {
filtered.push(event);
}
}
return filtered;
};Aの例を見たあとにBの例を見ると、なんだこのヘタクソなBは！ これ書いたやつ屋上（に来いや）！ って感じですよね。
あるいは、新手の行数稼ぎか！？（行数増やしたことに意味はあるのか!?）と思われるのかもしれません。もちろん、Bの例は行数稼ぎなどではなく、検証を経て現時点で最速と考えられているコードです。
Aは RPGツクールMV（1.6.1）のコアスクリプトからの引用です。
Bは seeaの書いた速度改善プラグイン（SA Core Speed Improvement v18.1）からの引用です。残念ながら JavaScript の実行エンジンのもとでは B のほうが高速に動作しますので、屋上には出向きません。
なぜそんなことが起こるのでしょうか？
見通しの良さを大切にする文化がある
コードの実行速度は結果の一つに過ぎず、それに固執するのは望ましくないとする文化（作法）があります。
実際のところ、速度よりも見通しの良さを重視して作られているプログラムが大半です。もちろん速いに越したことはありませんが、速度が正義、ではないのです。
つまり、いくら速いからといって A のコードを B のように書くのは、書くことはできますが、本当に B のように書いて提出したりはしないのです。その点において、コードの速度を何よりも重視する者は、むしろ異端なのです。
A のコードを大切にする人にとっては、なぜ B のような書き方をしなくてはならないのか、意味が分かりません。コードを B のようにするテクニックは、根本的な対策ではなく小手先のことに始終しており、そのことが強い抵抗感のもとになっているのかもしれません。
本来であれば、JavaScriptの実行エンジン側が最適化で対応すべきことであり、同じ処理を行うのに何通りかの書き方があるからといって、そのうちの最速のコードを探すという行為は、プログラマがすることではない。そう考えているのかもしれません。
ゲーマー優先なら速度優先となるが……
ゲーマー（プレイヤー）の都合を最優先に考えるならば、制作者側の事情など知ったことではありません。スクリプトが綺麗に書かれていようが、混沌としていようが関係ないのです。MVが重いと言われるのなら、提供側としては最速のコードを見つけ出した上で、プレイヤーに動かしてもらうのが理に適っているとゲーマー的には思うのですが、実際はそうではありません。
現在のRPGツクールMV（バージョン 1.6.1）は、最速とは言えないコアスクリプトで動いていますので、そりゃ遅いと言われることもあるでしょう。PCやスマホのスペックが上がるにつれて自然と解決していくこと、と考えられているフシもあります。確かにそうなのかもしれません。
「そういうのは、プラグインでやってくれ」への回答
それでも私は、プラグイン制作者である以前に、ゲーマーの端くれです。プログラマや設計者の都合を無視してでも、ゲーマーにとって必要なことを行います。その必要なことの一つが、速度改善プラグインの追加です。
コードの見通しは良いが実ゲームの速度を遅くするコードを、見通しは悪いが機能は同等の、Chromeブラウザが高速に処理するコードに置き換え、ゲームの速度の改善を目指します。
速度改善プラグインはどこかで配布していますので、興味をお持ちの方は探してみてください……。