今回作っているSTGは完全にオブジェクト指向で「いかに適切な設計をするか」を求めようと思っています。

■お詫びと訂正■
vectorをoperator[]でアクセスし、flag参照関数をinline化し、最適化かけたら同じ速度になりました。。。


汎用的・拡張性の高い(便利な)設計は、実行効率や速度が低下しがちです。
しかし、リソースが豊富な現在、実行効率を少々犠牲にしても、便利な設計を重視する方が良いという考え方もあります。
そこで、便利な設計⇔実行効率のトレードオフをどの辺で判断すべきか、検証してみました。

弾幕ゲー制作の中で一番肝になるのが、「弾」データの持ち方。
弾データは弾クラスの一つのオブジェクトですが、持ち方は以下の4通り位あるでしょう。

遅
↑
・メモリプールから確保できる形でlistを使う(new,deleteを繰り返す弾オブジェクトのリスト)
・タスクリストを使う
・vectorを使う
・配列を使う
↓
速

実行速度は上ほど遅い、下ほど早いと思われます。(vectorは安全に.at(i)でアクセス)

まずは、配列とvectorでどれ位変わるか調べてみました。

約5万個の弾を出した時の計算時間

[vector編]

計算部 = 915[ms]
描画部 = 27[ms]

[配列編]

計算部 = 267[ms]
描画部 = 16[ms]

なんと！vectorは配列の約3.5倍！
かなり処理に時間がかかるようです。
あらゆるアクセスに関数コールが生じるのがボトルネックのようです。(特にat?)
そこで、関数コールをなるべくしないように考えます。

弾クラスにはその弾が使用中かどうかを表すフラグ変数がありますが、この変数はprivateなので

bool IsUsing();

みたいな関数を通じてしか使用中かどうかチェック出来ません。
しかし、膨大な回数のこの関数コールが生じています。そこで、フラグ変数をpublicにし、直接参照するようにし、配列版をさらに高速に計算出来るように試みました。
すると・・・

[配列+関数コール削減版]

計算部 = 49ms
描画部 = 16ms

計算時間が約1/18になったではないですか！
どうも関数コールは相当なボトルネックになるようです。
とは言え、汎用性や拡張性を意識すると、どうしても関数に細分化しがちです。
この辺のトレードオフは基準が難しそうですが、頻繁にコールする関数はなるべく作らないように設計するのが良いようです。
（ちなみに上記関数はinlineにしても変化ありませんでした。使い方が悪いのかな・・）
※追記：最適化かかってないだけでした；

もっとこうすればいいとかあれば、何かご意見もらえると嬉しいです！

CBullet* p;
みたいなもの用意して、アクセスする度にp++;をするってことですか？
計算が入る分余計に遅くなりません？

簡単なコードの実装状態を教えて下さいね。

then節ってなんです・・？

あっとC/C++なら真になる条件の確率が高くなるようにして下さいということです。
Pascal/FORTRAN/BASICだとそう言うので、つい・・・。

> softyaさん

あ～例えば構造体配列だとすると って参照の方が速いってことですか？

> then節

なるほど。 これはproc1()が呼ばれる可能性が高いようにした方がよいということですか？

２～３つ以上参照すると速いはずです。
あと じゃないと意味が無いですね。

これはproc1()が呼ばれる可能性が高いようにした方がよいということですか？

thenの確率が高いなら、elseが無いほうが速いと言う話ですね。
場合によってですが、 よりも が速いはずですが、昨今のコンパイラの最適化とCPUのパイプラインの挙動までは把握しきれてません。

なるほど。
しかし上の場合、「p++」という余計なインクリメント計算が入りますが、それでもなお速いということですか？
実際の測定は明日やってみようと思います。

配列の高速アクセスはこうですね。 でもリストを活用したほうが速いですよ。
使用中弾リストを作れば弾の存在確認自体が要らなくなります。
他の弾に依存する処理も依存弾リストを持たせれば良いです。
メモリプールも、事前に確保したメモリをリスト管理して、オーバーライドしたnewで使用していないメモリのリストから取り出して使用しているリストに移動、オーバーライドしたdeleteで使用しているリストから使用していないリストに移動、って感じに。

Dixq (管理人) さんが書きました:>パコネコさん

リストはありだと思うんですが、弾幕って何かの弾に依存した動きする時、特定の弾にアクセスしたい時ありません？
4000個ある内の2000番目の弾とか・・。
そうなるとリストって一気にアクセスが遅くなるんじゃないかと思います。

弾幕のプログラムは書いたことがないですが、
自分だったら特定の弾に関連した動きをさせたい場合は弾を生成した時点で、
弾自体に他の弾へのポインタを持たせる方法を使うと思います。
そうすればlistへのランダムアクセスは発生しないので。

内部で頻繁にアロケートしたりしてもvectorが遅くなるとは思います。通常、push_backする前にreserveしておくのが定石ですが…
VisualC++では、最適化をかければvectorは大抵の関数がインライン展開されて普通に動的配列使うのと全く同一のコード、あるいはそれに近いコードが生成されるはずです。

> ISLeさん
> カロさん

>他の弾に依存する処理も依存弾リストを持たせれば良いです。

依存した弾のポインタを持たせるということですか？
同じ実体を示すポインタが複数あるというのはあまり・・な気がするんですが、私の認識違いでしょうか。
実体deleteしたのに、参照しちゃうとか。

> tkさん

vectorでpush_backは使ってないですね～。なのでatも使わないし、特にvector化する必要性も感じてないです。

Dixq (管理人) さんが書きました:同じ実体を示すポインタが複数あるというのはあまり・・な気がするんですが、私の認識違いでしょうか。
実体deleteしたのに、参照しちゃうとか。

そういうときのためのスマートポインタですよ。
参照されなくなったらオブジェクト自身がdeleteする設計にすると、ダングリングを回避できます。

(追記)
まだ参照されているのに実体が削除できてしまうのは問題なので、参照が無くなるまでオブジェクトの破棄が保留されるようにすべきです。
参照する側とされる側をどちらから削除するかという順番を気にしなくても良くなるというメリットもあります。

> ISLeさん

なるほど・・・。今までの疑問がすごく晴れました。。。
まだまだC++初心者なので、情報ありがたいです。
早速あちこち修正してきます。