2011|08|
2013|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|05|06|07|08|09|10|11|12|
2016|01|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|

2019-04-01 検証:STLを使うと実行速度が「遅くなる」?

検証:STLを使うと実行速度が「遅くなる」?

検証:STLを使うと実行速度が「遅くなる」?

  • date

    • 2019/04/01

  • 原本

  • 1.動機
    • ■18年度は、ソフト外注会社さんのお勧めもあって、リスト構造体に"STL"を採用してみた
    • ■この辺については、この記事の最終章が役に立つかも
  • 2.感想
    • (1)確かに便利
      • メモリリークの心配をしなくて良いのは、安心
    • (2)今までできていたことができなくなった
      • リストの要素の中身を、<list>のメソッドを使わなければ触れないのは、正直"痛い"
      • 動的メモリの内容を、複数のリストに一斉に影響させる、ということができなくなるのは、かなり"痛い"
    • (3)上記(2)に関しては、メモリを配列にすることで回避できることとのアドバイスを貰ったが、それって、一度、スタティックメモリを事前に確保しておかなければ、美味しくない
      • 個人的には、オブジェクトは1つにして、色々なところからアクセスできるようにしたい
      • だって、開発者は、私一人だけなんだから
  • 3.コーディングの上での問題点
    • (1)GDBのデバッグで、STLのライブラリのソースコードの中に入り込んで、2ステップ以上の手続が必要となり、滅茶苦茶イライラする(多分、解消法はあるんだろうが、見つけられていない)
  • 4.実行上の問題
    • 仮説:STLを使うと実行速度が「遅くなる」
      • デバッグ時のローディングは、間違いなく、滅茶苦茶遅い
  • 5.本当に遅いのか?
  • 6. 考察
    • ■これは、江端の環境での話であって、他の環境では異る結果が出るかもしれない
    • ■江端は研究目的でプログラムを作っているので、保守環境などを考えれば、「STLの使用が正解である場合」がある
      • 実際、江端は、後輩にC/C++ without STLなどを進めていない
      • 新人なら、STLやpythonを勧めると思う