views:

227

answers:

4

I have automatic generated code (around 18,000 lines, basically a wrap of data) and other about 2,000 lines code in a C++ project. The project turned on the link-time-optimization operation. /O2 and fast-code optimization. To compile the code, VC++ 2008 express takes incredibly long time (around 1.5 hours). After all, it has only 18,000 lines, why the compiler takes so much time?

a little explanation to the 18,000 code. It is plain C, not even C++ which includes many unpacked for-loop, a sample would be:

a[0].a1 = 0.1284; a[0].a2 = 0.32186; a[0].a3 = 0.48305; a[1].a1 = 0.543; ..................

It basically fill a complex struct. But not so complex to compiler I guess.

The Debug mode is fast, only the Relase mode has this issue. Before I have the 18,000 lines of code, they are all fine. (that time the data is in external location). However, the release mode does many work which reduce the size of exe from 1,800kb to 700kb.

this issue does happen in link stage because all .obj files are generated. I have suspect on link-time-code-generation too but cannot figure out where is wrong.

+3  A: 

Several factors influence link time, including but not limited to:

  • Computer speed, especially available memory
  • Libraries included in the build.
  • Programming paradigm - are you using boost by any chance?

18,000 lines of template metaprogramming compiling on even a new quad-core and 1.5 hours of linking wouldn't completely surprise me.

280Z28
Yeah, sometimes it took 3 hours to build the project completely.
Sorantis
I did some experimenting with `boost::spirit` - built a full parser for an actual language with it. Even at under 1000 lines it took forever.
280Z28
template meta programming has of course nothing to do with linking
anon
@Neil: No, but 50,000 character expanded types do.
280Z28
@Neil: Also remember that VC does link-time code generation. Most of the link time in his configuration is the cross-method optimizer, which operates globally as opposed to constrained per file.
280Z28
Well, given MS's history with linkers, perhaps it shouldn't? And if you enable optimisations that you probably don't need, and which may well not work, you must expect a performance hit.
anon
@Neil: How is that helpful? If you want to help, try to get past your bias and figure out the particular section of the link stage that's causing a hit. You're rather annoying me in this thread because you're letting your bias get in the way of willingness to help, and given your reputation level you should be a leader in avoiding the lure of that.
280Z28
+1  A: 

Historically, a common cause of slow C++ computation is excessive header file inclusion, usually a result of poor modularization. You can get a lot of redundant compilation by including the same big headers in lots of small source files. The usual reference in these cases is Lakos.

You don't state whether you are using the pre-compiled header, which is the quick and dirty substitute for a header file refactoring.

Steve Gilham
The question is about the link stage, not the compile stage. While excessive header file inclusion and poor modularization can easily lengthen the compile stage, I'd think them irrelevant to linking.
David Thornley
Once again, nothing to do with linking.
anon
Correct me if I am wrong, but the culling and reconciliation of duplicate definitions in distinct object code modules -- something that can arise from poorly modularised header inclusion -- is IIRC a link-time operation.
Steve Gilham
A: 

That's why we generate lots of DLLs for our debug builds, but generally link them in for our release builds. It's easier (for our particular purposes) to deal with more monolithic executables, but it takes a long time to link.

David Thornley
A: 

As said in one of the comments, you probably have Link Time Code Generation (/LTCG) enabled, which moves the majority of code generation and optimization to the link stage.

This enables some amazing optimizations, but also increases link times significantly.

The C++ team says the've significantly optimized the linker for VS 2010.

peterchen