Q&A
VSバージョンおよびプロジェクト設定の 構成プロパティ > C/C++ > 全般 > SDLチェック の値を確認、追記ください。
下記の数千行にもわたる構造体の初期化ですが、リリースバージョンのビルドにおいて、「コード生成しています。」という出力メッセージから30秒くらいかかり、プログラムが作成されるのに時間がかかってしまいます。（デバッグ時は数秒もかからないですが、リリース時に時間がかかります）
膨大なデータを持つプログラムの書き方としては適さないのでしょうが、構造体の初期化の記述をなるべく崩さず、代替となる方法などがあればご教授いただきたいです。
宜しくお願いします。
開発環境はvisual studio 2005、MFCのダイアログベースのアプリケーションです。_T("****")の内容は少ない時で半角20文字程度、多い時で半角100文字以内になります。
補足１：CStringをchar [256]にすると、5秒でビルドは完了しました(ほぼ普通のビルドです)。CStringが以上に初期化を行っているからかもしれませんが、デバッグとビルドでこんなに時間の差がつくのが理解できません。
補足２：CStringとしたまま、リリースの構成プロパティ＞C/C++＞最適化の欄で、デバッグと同じく最適化、プログラム全体の最適化ともに無効にすると、数秒でビルドは完了するのですが、下記のエラーを吐き出しました。
LINK : /LTCG が指定されましたが、コードの生成は必要ありません。リンク コマンド ラインから /LTCG を削除し、リンカの性能を改善してください。
また、最適化のみ無効にすると、エラーはないですが10秒はかかります(約20秒短縮)、プログラム全体の最適化のみ無効(いいえ)にすると、変化はありませんでした。
static TEST_BUFFER TESTNAME [] = { { _T("****"), _T("****"), _T("****"), _T("****") }, ～（以下数千行続く） }; typedef struct _TEST_BUFFER{ CString buffer1; CString buffer2; CString buffer3; CString buffer4; } TEST_BUFFER;
s/SDL/STL/
？Security Development Lifecycle (SDL) です。
TEST_BUFFERの定義も必要ですので記載ください。これに依存すると思います。
そんな項目あったのかー！(すいませんすいません)
いつのまにか増えてましたね～ 気にしたことなかったですけど。
いえ。お気になさらず^-^
回答6件
3
こんにちは。
msvc2015とMinGW(gcc) 5.4.0でやってみましたが、1秒かかりません。
TEST_BUFFERの中身はint型4つとfloat型4つです。
8000行以上定義してます。
TEST_BUFFERはどんな定義なのでしょうか？
constexprコンストラクタで非常に重たい処理をしているということはないでしょうか?
投稿2017/07/07 08:34
総合スコア23259
回答へのコメント
開発環境はVisual Studio 2005、
構造体の中身は、CString（MFC）の文字列です。
デバッグでは数秒もかからないですが、リリースになると途端に重くなります。
Visual Studio 2015でやってみました。debug/release共に時間がかかりました。高々3,000行くらいで10秒近くかかります。
std::wstringにすると僅かに速くなった感じですが、大差ありません。
wchar_t const*（もしマルチバイト文字ならchar const*）でポインタのみ受け取れば高速になります。
struct TEST_BUFFER
{
wchar_t const* a;
wchar_t const* b;
wchar_t const* c;
wchar_t const* d;
};
確かに、CStringをchar [256]にすると、5秒でビルドは完了しました。でも、CStringを前提としたコードを書いていたので、charにはできるだけしたくないという理由があります・・・。
プロパティの設定をいじると若干早くなったりもしますが（追記してます）設定を変えるのが知識不足で怖い状況です・・・。
該当の初期化部分についてのみ#pragmaで最適化を禁止してみると良いかもしれません。（Visual Studio 2015では効果ありました。）
https://msdn.microsoft.com/ja-jp/library/chh3fb0k(v=vs.80).aspx
https://msdn.microsoft.com/ja-jp/library/chh3fb0k.aspx
コンパイル単位（*.cpp）の最後に下記を置くイメージです。
#pragma optimize( "ts", off )
static TEST_BUFFER TESTNAME [] =
{
：
};
push/pop(最適化オプション)があれば、release/debugの両方共元に戻せるのでコンパイル単位の最後に持ってくる必要はないのですが．．．
質問の配列はヘッダで定義しているのですが、そのヘッダをインクルードしているcppの最初と最後に上記のOffとonの"pragmaを定義してみましたが、速度に変わりはありませんでした。（使い方が今一つ理解できてないのでしょうが）
必ずcppの下にpragmaとバッファを書かないといけないのでしょうか？(定義が後ろにあるとビルドが通らないと思いますが・・・理解が乏しくてすみません)
#pragma optimize( "ts", off )
static TEST_BUFFER TESTNAME [] =
{
：
};
#pragma optimize( "ts", on )
ヘッダにこう書きました。
そんな巨大な配列をヘッダでstatic定義するのはあまりよろしくないと思います。そのヘッダをインクルードしているcpp全てで同じ配列が定義されますので。もしかすると最適化で重複を削除してくれる可能性はありますが、当然その分コンパイル時間が伸びます。
ヘッダでは extern TEST_BUFFER TESTNAME [];としておき、どれか１つのcppで下記のように定義することをお勧めします。
#pragma optimize( "ts", off )
TEST_BUFFER TESTNAME [] =
{
：
};
↓が参考になるかも知れません。
http://mywebnote.blog.jp/archives/1061503744.html
---
【追記】
あっとコメントが行き違いました。
その記述でコンパイル時間は削減出来ても良いと思いますが、複数のコンパイル単位間で最適化しようとしている可能性は残ります。2015と2005の相違と言う可能性も残りますけど。
static定義のヘッダをインクルードしているのは一か所のcppだけなので、配列の定義は一か所だけになっています。(ただしそのstatic定義の変数のstructの定義ファイルはまた別にあって、それはほぼすべてのファイルでインクルードされています）
staticでありながら、staticであることを想定していない(一か所だけにあることを想定している)間違ったｺｰﾄﾞなのですが・・・。
また、そのstruct定義自体は、他のcppで関数の引数の型として色んな所で使われています。
なので、要は、実体のあるところで最適化が行われてなければいいのですが、どうもうまくいかないようです。
確か、構造体の受け渡しをしているcppファイルや関数が増えていくたびに重くなったような気もしますが、根本はCStringの初期化にあると思うので、これからは作り方を考慮しないといけないですね。
とりあえず自分の中でいくつか解決方法が浮かんだので解決済とします。至らぬ点が多々ありましたが、皆さんありがとうございました。また、他に有効な方法があれば引き続き受け付けております。
> static定義のヘッダをインクルードしているのは一か所のcppだけなので、配列の定義は一か所だけになっています。
であれば、cppで定義するのと同じですね。（最後にonするとそれ以降のコードについてdebug時もonになるので、コンパイル単位の途中でやるのはあまりお勧めしませんが。）
しかし、１箇所だけなのに#pragma optimize( "ts", off )の効果がないのは不思議です。2015と2005の仕様の相違ですかね。
下記だけを定義したcppファイルを追加して、そのファイルのみreleaseの最適化オプションをdebugと同じにすれば解決しそうな気がします。
TEST_BUFFER TESTNAME [] =
{
：
};
> 構造体の受け渡しをしているcppファイルや関数が増えていくたびに重くなったような気もしますが
その度にstatic TEST_BUFFER TESTNAME [] = {...};をインクルードしている可能性を感じます。
TESTNAME[]配列を受け渡すだけであれば、それはボインタを渡しているだけですから、コンパイル時間に影響があるとは考えにくいです。
はい。ただ、自動的に色んなcppでincludeしているのであれば、staticを外すとたちまちエラーにはなるので考えにくいのですが・・・。
試しに、いろんなcppで問題のstatic配列をインクルードしてみると、確かに生成が遅くなった(約40秒)のですが、インクルードしている数で掛け算的に遅くなりませんでした。詳しくは調べていませんが、単一のcppでインクルード(20秒)か、複数のcppでインクルード(40秒)かという感じでした。
なるほど。staticを外してもリンク・エラーにならないのであれば複数のコンパイル単位でインクルードしていることは無いはずですね。
手元にmsvc 2005はないし、2015では再現しないので私の方ではこの辺が限界のようです。お役に立てず申し訳ないです。頑張ってください。
ありがとうございました。
1
(コード内容も本当は気になりますが…)
デバッグビルドの設定と、リリースビルドの設定は、初期値のままですか?
構成が変わっていると、思わぬところで時間がかかることがあります。プリコンパイル済みヘッダとかプリコンパイル済みヘッダとかプリコンパイル済みヘッダとか。(以前泣かされた)
よろしければ、設定内容を見せてもらえませんか?
参考文献：
http://d.hatena.ne.jp/unarist/touch/20110322/1300748204
投稿2017/07/07 09:16
総合スコア1718
回答へのコメント
とりあえずデバッグとリリースの違いですが、全てを見たわけではありませんが、リリースでは最適化：実行速度 (/O2)、プログラム全体の最適化：リンク時のコード生成を有効にする (/GL)としており、デバッグではいずれも無効でした。デバッグと同じようにしたら、数秒でビルドは完了しました。
構成プロパティ > C/C++ > 最適化の欄にあります。
最適化、プログラム全体の最適化ともに無効にすると、数秒でビルドは完了するのですが、エラーを吐き出しました。
LINK : /LTCG が指定されましたが、コードの生成は必要ありません。リンク コマンド ラインから /LTCG を削除し、リンカの性能を改善してください。
最適化のみ無効にすると、エラーはないですが10秒はかかります(約20秒短縮)、プログラム全体の最適化のみ無効(いいえ)にすると、変化はありませんでした。
1
恐らくですが、include パスが多すぎる、もしくは include パスの中に含まれるファイルが多すぎるのだと思います。
include パスの順を見直すか、必要ない物を削ってみてはどうでしょうか？
※あとあるとしたらインクリメンタルリンクくらい？
投稿2017/07/07 09:10
総合スコア5030
回答へのコメント
逆に、この配列を削るとビルドは数秒で終わりました。そして、この配列を加えるととたんに重くなるので、この配列の初期化が遅いのだろうと踏んでいます。
実は結構スペックが低いとかですか？
あと、だとするとプリコンパイルヘッダとか効いてきそうな気もします。
PCのスペックは問題ないです。CPUはi7-4790 メモリは8ギガです。リリース、デバッグともにプリコンパイル済みヘッダを使用するとなっていて、作成するに変更するとエラーが起きます。使用しないと当然ですがめちゃくちゃ遅くなりました・・・。
1
開発環境はvisual studio 2005なので、以下の回答は今回のケースには当てはまりません。
ビルドが止まってしまう
にて「コード生成しています。」から時間がかかるという同様の質問があがっています。
上記ではSDLチェックに時間がかかっていたとの結論に至っています。
/sdl (追加のセキュリティ チェックの有効化) によると
/sdl を有効にすると、実行時に次のチェックを実行するコードがコンパイラによって生成されます。
クラス メンバーの初期化を実行します。 すべてのクラス メンバーをオブジェクトのインスタンス化時にゼロに自動的に初期化します (コンストラクターの実行前)。 これは、コンストラクターが明示的に初期化しないクラス メンバーに関連付けられた、初期化されていないデータの使用を防止するために役立ちます。
とのことなので、これに時間がかかっているのかもしれません。
ただ、OFFにするとビルド速度はあがる可能性ありますが、30秒程度ですし、コードの安全性を損なうのでONのままのほうがよいと思います。
参考：Security Development Lifecycleチェックボックスとは何か？
なお、SDLがOFFまたは、お使いのVSが2010以前であればSDLチェックがないので、原因は別にあります。
投稿2017/07/07 08:39
編集2017/07/07 08:48総合スコア37453
0
自己解決
とりあえず自分の中でいくつか解決方法が浮かんだので解決済とします。至らぬ点が多々ありましたが、皆さんありがとうございました。また、他に有効な方法があれば引き続き受け付けております。
現時点での解決方法（まだほかにもあるかもしれません）
１．CStringではなくcharの配列にする。（これからの課題）
２．頻繁にビルドを掛ける際は、できるだけデバッグ環境で動かし、最終段階としてリリースバージョンをビルドする（暫定的な回避方法）
３．問題となっている箇所をDLL化し、問題の配列の実体を持っているプログラムを最小限に切り取り隔離する。（他の変更を加えたときのビルド時間の節減。プログラムが分断するデメリットもあり）
投稿2017/07/07 11:17
編集2017/07/07 11:19総合スコア31
0
ビルド後のbinaryを覗いてみたい気持ちがありますが、原因は明らかにCStringのコンストラクタの最適化でしょう。おそらくCStringコンストラクタ処理後の状態をそのままbinaryに埋め込むとかそういうことをやっているのではないでしょうか。
とりあえずそのstatic変数があるファイルを分けて再コンパイルをあまりしなくていいようにしてみるとかでしょうか。
Chironianさん提案の構造体をいじることや、配列として文字列をもたせるのは、実行時にCStringコンストラクタコストを削れないことになると思うので(こんなの最適化できるんですね)コンパイル時間は犠牲に捧げるべきかと思います。
投稿2017/07/07 09:51
総合スコア5850
回答へのコメント
何となく原因がわかってきました。ただ、現在の環境では、どこでどんな変更があってもコード生成に時間がかかっています。頻繁にビルドを掛ける際は、できるだけデバッグ環境で動かし、最終段階としてリリースバージョンをビルドする、というのが暫定的な回避方法ですかね。
linkerに時間がかかっているのか・・・。するとそうするしかないですね・・・。一回コマンドでコンパイルして時間計測してみるべきかも
ちなみにbinaryの大きさってどうなってますかね？もしかしたらリンカーの動作がメモリー律速、もしくはDisk IO律速になっていませんか？リンク中のDisk IOやメモリーUsageを監視してください
バイナリとは何のことでしょうか？（初心者の疑問ですみません）ただ、実行プログラムのバイトサイズは、当配列を入れると600キロバイト膨れ上がりました（苦笑）
>バイナリとは何のことでしょうか？
>実行プログラムの
伝わっているようで何よりです
あなたの回答
tips
プレビュー
