質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.51%
MFC

MFC (Microsoft Fouondation Class)とは、MicrosoftがVC++用に開発したWindows用アプリケーションのフレームワークです。

Visual Studio

Microsoft Visual StudioはMicrosoftによる統合開発環境(IDE)です。多種多様なプログラミング言語に対応しています。

コンパイル

コンパイルとは、プログラミング言語のテキストソース(ソースコード)をコンピュータ上で実行可能な形式(オブジェクトコード)に変換することをいいます

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

Q&A

解決済

6回答

1280閲覧

構造体の初期化指定子が膨大な場合、コード生成に時間がかかる問題

Angkorwat

総合スコア31

MFC

MFC (Microsoft Fouondation Class)とは、MicrosoftがVC++用に開発したWindows用アプリケーションのフレームワークです。

Visual Studio

Microsoft Visual StudioはMicrosoftによる統合開発環境(IDE)です。多種多様なプログラミング言語に対応しています。

コンパイル

コンパイルとは、プログラミング言語のテキストソース(ソースコード)をコンピュータ上で実行可能な形式(オブジェクトコード)に変換することをいいます

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

0グッド

6クリップ

投稿2017/07/07 07:51

編集2017/07/07 09:43

下記の数千行にもわたる構造体の初期化ですが、リリースバージョンのビルドにおいて、「コード生成しています。」という出力メッセージから30秒くらいかかり、プログラムが作成されるのに時間がかかってしまいます。(デバッグ時は数秒もかからないですが、リリース時に時間がかかります)

膨大なデータを持つプログラムの書き方としては適さないのでしょうが、構造体の初期化の記述をなるべく崩さず、代替となる方法などがあればご教授いただきたいです。
宜しくお願いします。

開発環境はvisual studio 2005、MFCのダイアログベースのアプリケーションです。_T("****")の内容は少ない時で半角20文字程度、多い時で半角100文字以内になります。

補足1:CStringをchar [256]にすると、5秒でビルドは完了しました(ほぼ普通のビルドです)。CStringが以上に初期化を行っているからかもしれませんが、デバッグとビルドでこんなに時間の差がつくのが理解できません。

補足2: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;

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

can110

2017/07/07 08:10

VSバージョンおよびプロジェクト設定の 構成プロパティ > C/C++ > 全般 > SDLチェック の値を確認、追記ください。
mattn

2017/07/07 08:27

s/SDL/STL/
can110

2017/07/07 08:36

?Security Development Lifecycle (SDL) です。
PineMatsu

2017/07/07 08:37

TEST_BUFFERの定義も必要ですので記載ください。これに依存すると思います。
mattn

2017/07/07 08:47

そんな項目あったのかー!(すいませんすいません)
can110

2017/07/07 08:49

いつのまにか増えてましたね~ 気にしたことなかったですけど。
can110

2017/07/07 08:50

いえ。お気になさらず^-^
guest

回答6

0

こんにちは。

msvc2015とMinGW(gcc) 5.4.0でやってみましたが、1秒かかりません。
TEST_BUFFERの中身はint型4つとfloat型4つです。
8000行以上定義してます。

TEST_BUFFERはどんな定義なのでしょうか?
constexprコンストラクタで非常に重たい処理をしているということはないでしょうか?

投稿2017/07/07 08:34

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Angkorwat

2017/07/07 08:37

開発環境はVisual Studio 2005、 構造体の中身は、CString(MFC)の文字列です。
Angkorwat

2017/07/07 08:37

デバッグでは数秒もかからないですが、リリースになると途端に重くなります。
Chironian

2017/07/07 09:13

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; };
Angkorwat

2017/07/07 09:48

確かに、CStringをchar [256]にすると、5秒でビルドは完了しました。でも、CStringを前提としたコードを書いていたので、charにはできるだけしたくないという理由があります・・・。 プロパティの設定をいじると若干早くなったりもしますが(追記してます)設定を変えるのが知識不足で怖い状況です・・・。
Chironian

2017/07/07 10:03

該当の初期化部分についてのみ#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の両方共元に戻せるのでコンパイル単位の最後に持ってくる必要はないのですが...
Angkorwat

2017/07/07 10:23

質問の配列はヘッダで定義しているのですが、そのヘッダをインクルードしているcppの最初と最後に上記のOffとonの"pragmaを定義してみましたが、速度に変わりはありませんでした。(使い方が今一つ理解できてないのでしょうが) 必ずcppの下にpragmaとバッファを書かないといけないのでしょうか?(定義が後ろにあるとビルドが通らないと思いますが・・・理解が乏しくてすみません)
Angkorwat

2017/07/07 10:26 編集

#pragma optimize( "ts", off ) static TEST_BUFFER TESTNAME [] = {   : }; #pragma optimize( "ts", on ) ヘッダにこう書きました。
Chironian

2017/07/07 10:33 編集

そんな巨大な配列をヘッダでstatic定義するのはあまりよろしくないと思います。そのヘッダをインクルードしているcpp全てで同じ配列が定義されますので。もしかすると最適化で重複を削除してくれる可能性はありますが、当然その分コンパイル時間が伸びます。 ヘッダでは extern TEST_BUFFER TESTNAME [];としておき、どれか1つのcppで下記のように定義することをお勧めします。 #pragma optimize( "ts", off ) TEST_BUFFER TESTNAME [] = {   : }; ↓が参考になるかも知れません。 http://mywebnote.blog.jp/archives/1061503744.html --- 【追記】 あっとコメントが行き違いました。 その記述でコンパイル時間は削減出来ても良いと思いますが、複数のコンパイル単位間で最適化しようとしている可能性は残ります。2015と2005の相違と言う可能性も残りますけど。
Angkorwat

2017/07/07 10:40

static定義のヘッダをインクルードしているのは一か所のcppだけなので、配列の定義は一か所だけになっています。(ただしそのstatic定義の変数のstructの定義ファイルはまた別にあって、それはほぼすべてのファイルでインクルードされています)
Angkorwat

2017/07/07 10:42

staticでありながら、staticであることを想定していない(一か所だけにあることを想定している)間違ったコードなのですが・・・。
Angkorwat

2017/07/07 10:44

また、そのstruct定義自体は、他のcppで関数の引数の型として色んな所で使われています。
Angkorwat

2017/07/07 10:44

なので、要は、実体のあるところで最適化が行われてなければいいのですが、どうもうまくいかないようです。
Angkorwat

2017/07/07 11:09 編集

確か、構造体の受け渡しをしているcppファイルや関数が増えていくたびに重くなったような気もしますが、根本はCStringの初期化にあると思うので、これからは作り方を考慮しないといけないですね。
Angkorwat

2017/07/07 11:18

とりあえず自分の中でいくつか解決方法が浮かんだので解決済とします。至らぬ点が多々ありましたが、皆さんありがとうございました。また、他に有効な方法があれば引き続き受け付けております。
Chironian

2017/07/07 11:30

> static定義のヘッダをインクルードしているのは一か所のcppだけなので、配列の定義は一か所だけになっています。 であれば、cppで定義するのと同じですね。(最後にonするとそれ以降のコードについてdebug時もonになるので、コンパイル単位の途中でやるのはあまりお勧めしませんが。) しかし、1箇所だけなのに#pragma optimize( "ts", off )の効果がないのは不思議です。2015と2005の仕様の相違ですかね。 下記だけを定義したcppファイルを追加して、そのファイルのみreleaseの最適化オプションをdebugと同じにすれば解決しそうな気がします。 TEST_BUFFER TESTNAME [] = {   : }; > 構造体の受け渡しをしているcppファイルや関数が増えていくたびに重くなったような気もしますが その度にstatic TEST_BUFFER TESTNAME [] = {...};をインクルードしている可能性を感じます。 TESTNAME[]配列を受け渡すだけであれば、それはボインタを渡しているだけですから、コンパイル時間に影響があるとは考えにくいです。
Angkorwat

2017/07/07 11:41

はい。ただ、自動的に色んなcppでincludeしているのであれば、staticを外すとたちまちエラーにはなるので考えにくいのですが・・・。 試しに、いろんなcppで問題のstatic配列をインクルードしてみると、確かに生成が遅くなった(約40秒)のですが、インクルードしている数で掛け算的に遅くなりませんでした。詳しくは調べていませんが、単一のcppでインクルード(20秒)か、複数のcppでインクルード(40秒)かという感じでした。
Chironian

2017/07/07 13:11

なるほど。staticを外してもリンク・エラーにならないのであれば複数のコンパイル単位でインクルードしていることは無いはずですね。 手元にmsvc 2005はないし、2015では再現しないので私の方ではこの辺が限界のようです。お役に立てず申し訳ないです。頑張ってください。
Angkorwat

2017/07/08 07:28

ありがとうございました。
guest

0

(コード内容も本当は気になりますが…)

デバッグビルドの設定と、リリースビルドの設定は、初期値のままですか?
構成が変わっていると、思わぬところで時間がかかることがあります。プリコンパイル済みヘッダとかプリコンパイル済みヘッダとかプリコンパイル済みヘッダとか。(以前泣かされた)

よろしければ、設定内容を見せてもらえませんか?

参考文献:
http://d.hatena.ne.jp/unarist/touch/20110322/1300748204

投稿2017/07/07 09:16

majiponi

総合スコア1720

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Angkorwat

2017/07/07 09:31

とりあえずデバッグとリリースの違いですが、全てを見たわけではありませんが、リリースでは最適化:実行速度 (/O2)、プログラム全体の最適化:リンク時のコード生成を有効にする (/GL)としており、デバッグではいずれも無効でした。デバッグと同じようにしたら、数秒でビルドは完了しました。
Angkorwat

2017/07/07 09:33

構成プロパティ > C/C++ > 最適化の欄にあります。
Angkorwat

2017/07/07 09:40

最適化、プログラム全体の最適化ともに無効にすると、数秒でビルドは完了するのですが、エラーを吐き出しました。 LINK : /LTCG が指定されましたが、コードの生成は必要ありません。リンク コマンド ラインから /LTCG を削除し、リンカの性能を改善してください。 最適化のみ無効にすると、エラーはないですが10秒はかかります(約20秒短縮)、プログラム全体の最適化のみ無効(いいえ)にすると、変化はありませんでした。
guest

0

恐らくですが、include パスが多すぎる、もしくは include パスの中に含まれるファイルが多すぎるのだと思います。

include パスの順を見直すか、必要ない物を削ってみてはどうでしょうか?

※あとあるとしたらインクリメンタルリンクくらい?

投稿2017/07/07 09:10

mattn

総合スコア5030

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Angkorwat

2017/07/07 09:28

逆に、この配列を削るとビルドは数秒で終わりました。そして、この配列を加えるととたんに重くなるので、この配列の初期化が遅いのだろうと踏んでいます。
mattn

2017/07/07 10:58

実は結構スペックが低いとかですか?
mattn

2017/07/07 10:59

あと、だとするとプリコンパイルヘッダとか効いてきそうな気もします。
Angkorwat

2017/07/07 11:07

PCのスペックは問題ないです。CPUはi7-4790 メモリは8ギガです。リリース、デバッグともにプリコンパイル済みヘッダを使用するとなっていて、作成するに変更するとエラーが起きます。使用しないと当然ですがめちゃくちゃ遅くなりました・・・。
guest

0

開発環境は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
can110

総合スコア38230

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Angkorwat

2017/07/07 08:41

開発環境はVisual Studio 2005です。プロパティに上記のSDLの項目がないのでどうしようかと迷っておりました。
can110

2017/07/07 08:45

了解です。2005はSDLチェック自体がないので別の原因ですね。何だろう?
guest

0

自己解決

とりあえず自分の中でいくつか解決方法が浮かんだので解決済とします。至らぬ点が多々ありましたが、皆さんありがとうございました。また、他に有効な方法があれば引き続き受け付けております。

現時点での解決方法(まだほかにもあるかもしれません)
1.CStringではなくcharの配列にする。(これからの課題)
2.頻繁にビルドを掛ける際は、できるだけデバッグ環境で動かし、最終段階としてリリースバージョンをビルドする(暫定的な回避方法)
3.問題となっている箇所をDLL化し、問題の配列の実体を持っているプログラムを最小限に切り取り隔離する。(他の変更を加えたときのビルド時間の節減。プログラムが分断するデメリットもあり)

投稿2017/07/07 11:17

編集2017/07/07 11:19
Angkorwat

総合スコア31

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ビルド後のbinaryを覗いてみたい気持ちがありますが、原因は明らかにCStringのコンストラクタの最適化でしょう。おそらくCStringコンストラクタ処理後の状態をそのままbinaryに埋め込むとかそういうことをやっているのではないでしょうか。

とりあえずそのstatic変数があるファイルを分けて再コンパイルをあまりしなくていいようにしてみるとかでしょうか。

Chironianさん提案の構造体をいじることや、配列として文字列をもたせるのは、実行時にCStringコンストラクタコストを削れないことになると思うので(こんなの最適化できるんですね)コンパイル時間は犠牲に捧げるべきかと思います。

投稿2017/07/07 09:51

yumetodo

総合スコア5850

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Angkorwat

2017/07/07 10:04

何となく原因がわかってきました。ただ、現在の環境では、どこでどんな変更があってもコード生成に時間がかかっています。頻繁にビルドを掛ける際は、できるだけデバッグ環境で動かし、最終段階としてリリースバージョンをビルドする、というのが暫定的な回避方法ですかね。
yumetodo

2017/07/07 10:09

linkerに時間がかかっているのか・・・。するとそうするしかないですね・・・。一回コマンドでコンパイルして時間計測してみるべきかも
yumetodo

2017/07/07 10:12 編集

ちなみにbinaryの大きさってどうなってますかね?もしかしたらリンカーの動作がメモリー律速、もしくはDisk IO律速になっていませんか?リンク中のDisk IOやメモリーUsageを監視してください
Angkorwat

2017/07/07 10:14

バイナリとは何のことでしょうか?(初心者の疑問ですみません)ただ、実行プログラムのバイトサイズは、当配列を入れると600キロバイト膨れ上がりました(苦笑)
yumetodo

2017/07/07 17:26

>バイナリとは何のことでしょうか? >実行プログラムの 伝わっているようで何よりです
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.51%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問