とりあえず抽象クラスのポインタをstd::listにぶち込んでタスクシステム風にしてみる
↓
1000個でFPS28ｗｗｗｗｗ
↓
コンパイラの設定を変えてみる
↓
1000個でFPS58
↓
ソート用の評価関数をinlineにしてみる
↓
1600個でFPS53

これ以上軽く出来る方法無いのかな…(´・ω・｀)

夢幻ノ月夜 さんが書きました:とりあえず抽象クラスのポインタをstd::listにぶち込んでタスクシステム風にしてみる
↓
1000個でFPS28ｗｗｗｗｗ
↓
コンパイラの設定を変えてみる
↓
1000個でFPS58
↓
ソート用の評価関数をinlineにしてみる
↓
1600個でFPS53

これ以上軽く出来る方法無いのかな…(´・ω・｀)

コンパイラの設定し直したら3000個でFPS60出ました( ;⊙´◞౪◟`⊙)

std::listは使い方を間違わなければ十分高速なので、それで速度がでないなら、設計に原因があるのだと思います。
普通ゲームプログラムは描画以外にはほとんど処理時間を食いません。
9割がた処理時間は描画時間だと思った方がいいでしょう。
そこに描画以外の処理時間が食い込んでいるのであれば設計がまずい可能性が高いです。
とりあえず測定するときコンパイルオプションでDebugからReleaseにしていますか？

Dixq (管理人) さんが書きました:std::listは使い方を間違わなければ十分高速なので、それで速度がでないなら、設計に原因があるのだと思います。
普通ゲームプログラムは描画以外にはほとんど処理時間を食いません。
9割がた処理時間は描画時間だと思った方がいいでしょう。
そこに描画以外の処理時間が食い込んでいるのであれば設計がまずい可能性が高いです。
とりあえず測定するときコンパイルオプションでDebugからReleaseにしていますか？

Releaseの設定の中からSTLの実行速度に関係ありそうな部分だけDebugに持ってきてみました
すると3000個でFPS60が

仮にvectorにしてみたらどうなりますか？

意味的に（挿入削除の位置や頻度的に）dequeやlistだろうと思う状況でも
vectorにしたらそっちの方が遥かに早かったという経験がわりとあります．

要素数が何個くらいで逆転(?)するのかわかりませんが，
例えば「個数少ないならバブルソートでいいじゃん」的な話があるように
データ構造についても個数次第ではvectorにするという選択もあると思います．

シーケンスコンテナって，そもそもとりあえずstd::vectorで，それで問題が出たらstd::dequeやstd::list使う，という認識だったりしますが……。
# Effective STLは遠くなりにけり。

> Releaseの設定の中からSTLの実行速度に関係ありそうな部分だけDebugに持ってきてみました

？？
意味がよく分かりません。
コンパイル設定はどっちなんですか？

それにしてもVisual Studioのデバッガって高性能だけど
超超超激遅ですよね...10倍ぐらい遅いんじゃないかあれ

つまりDebugビルドならReleaseビルドにして最適化を実行速度最大化にしたら10倍早くなるんじゃねということ

Releaseビルドなのにその速度なら相当無駄な事してそう...

とりあえずprintfDxとGetNowCountなりで色々時間計測して見たりをおすすめします
printfDx便利すぎる

Dixq (管理人) さんが書きました:> Releaseの設定の中からSTLの実行速度に関係ありそうな部分だけDebugに持ってきてみました

？？
意味がよく分かりません。
コンパイル設定はどっちなんですか？

DebugでやってましたがReleaseにしてみたら18000個でも処理落ちほぼ0でした

Hiragi(GKUTH) さんが書きました:それにしてもVisual Studioのデバッガって高性能だけど
超超超激遅ですよね...10倍ぐらい遅いんじゃないかあれ

つまりDebugビルドならReleaseビルドにして最適化を実行速度最大化にしたら10倍早くなるんじゃねということ

Debugビルドは，Debug用に最適化処理はされないですし，標準ライブラリも状態を細かくチェックをしています。

例えば，コンパイラ側では，default-initializeされたプリミティブな型のオブジェクトは0xCDを全バイトに埋め込みます。
また，バッファオーバーフローを検出するために，mallocされたりした領域にさらに0xCCが埋め込まれた領域を用意しますし，解放時にその領域の値が変化していないかチェックします。

ライブラリだと，例えばstd::vector::iteratorの逆参照1つでも，有効な範囲内かどうかを調べています。
# VS2015Upd2のvectorだと64行目から。

これらはReleaseビルドではまったく行われません。
std::vector::iteratorの逆参照は，*_Ptrと，ポインタの逆参照そのものと最終的に同等になります。


一応Releaseビルドでもデバッガをアタッチできますが，Debugビルドに比べて非常にデバッグがしにくくなるかと。
そもそも，デバッグ時に速度が遅いと困るアプリケーションは特殊なので，デバッグ時にバグを見つけやすいことに重点を置いた構造になっているかと。

YuO さんが書きました:

Hiragi(GKUTH) さんが書きました:それにしてもVisual Studioのデバッガって高性能だけど
超超超激遅ですよね...10倍ぐらい遅いんじゃないかあれ

つまりDebugビルドならReleaseビルドにして最適化を実行速度最大化にしたら10倍早くなるんじゃねということ

Debugビルドは，Debug用に最適化処理はされないですし，標準ライブラリも状態を細かくチェックをしています。

例えば，コンパイラ側では，default-initializeされたプリミティブな型のオブジェクトは0xCDを全バイトに埋め込みます。
また，バッファオーバーフローを検出するために，mallocされたりした領域にさらに0xCCが埋め込まれた領域を用意しますし，解放時にその領域の値が変化していないかチェックします。

ライブラリだと，例えばstd::vector::iteratorの逆参照1つでも，有効な範囲内かどうかを調べています。
# VS2015Upd2のvectorだと64行目から。

これらはReleaseビルドではまったく行われません。
std::vector::iteratorの逆参照は，*_Ptrと，ポインタの逆参照そのものと最終的に同等になります。


一応Releaseビルドでもデバッガをアタッチできますが，Debugビルドに比べて非常にデバッグがしにくくなるかと。
そもそも，デバッグ時に速度が遅いと困るアプリケーションは特殊なので，デバッグ時にバグを見つけやすいことに重点を置いた構造になっているかと。

じゃあデバッグモード(処理落ち)前提で避ける弾幕をお遊びで用意してみましょうかね