𡈽方 雅之@プロセス思考

JavaScript も 結局 C言語 いまBABYLON.jsで開発中のゲームは、100体以上のキャラクターを60fpsで長時間動かすので、GC を極限まで減らさねばならない。毎フレーム動かす処理では、暗黙的なオブジェクト生成も見つけて潰す必要がある。 また、グローバル定数を壊して、影響が出るはずの無い他のキャラクターの速度や色が変わるというバグを、何度か起こしてしまった。これも防がねばならない。 いろいろ考えて導き出した答えが、コレ： 「プリミティブ以外、イコールは使用禁止」 もう、これで行こう。例外は「明示的に対象オブジェクトへの参照を保持したいケース」「関数の引数として構造体を渡すケース」。これ以外は「イコールを見つけたら、あやしい」と思うことにする。 クラスの construct時に、プロパティであれテンポラリ変数であれ、メモリを使うものは全てプリアロケーションし、毎フレームの処理では一切、動的なメモリ確保は行わない。 ……あぁ、これは、マシン語やC言語でゲームを作る時には当然だった感覚だったな。思い出した。 「プリミティブ以外、イコールは使用禁止」 （効果１）参照共有の事故を完全に防ぐ Vector3 / Color3 / Quaternion / Matrix / Array など、JavaScript の参照型は、「イコールで渡した瞬間に共有」になり、定数破壊事故の根源となる。規約で禁止すれば、事故はゼロ。 （効果２）暗黙的な new を完全に排除 ベクトルの add(), subtract(), scale() など多くのメソッドはイコールでの代入時に内部で new を行う。これを ～InPlace()系関数、～ToRef()系関数、.set()関数、.copyFrom()関数 など「既にメモリ確保されているものを更新する関数」に置き換える。結果、見た目からもイコールが消える。これで GC を完全に抑制できる。 （効果３）プリアロケーションが徹底される 「イコール禁止」を実現するには、その前提として「constructorで全ワーク変数を確保」「update()内で一切newしない」が徹底されることになる。見た目で判断できるので、コードレビューが圧倒的に楽になる。 それでも残るイコールは、プリミティブか、ライフサイクルが厳密に管理されている他キャラクターのインスタンスへの参照を保持する場合だけになるはず。実際、この方針でプログラムを書き換えて、100体以上のキャラクターで20万程度のArrayが発生した状態で２時間以上回したがHeapは全く増えずフルGCも一度も掛からなかった。よしよし。