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