Compiling takes hours to complete

Franck,

Can you check the page below? It helps understanding what is involved in the link process and gives some tips to reduce its time. 

http://processors.wiki.ti.com/index.php/Linker_Runs_Too_Long

Hope this helps,

Rafael

Franck,

Regarding the specific file which is taking a long time to compile (as opposed to slow link time), does it have a very large single function? Usually things can slow down when there are very large functions in a source file, and breaking the function into two or more smaller functions could speed up the compile time. Also if you're turning on inlining in your build options you could try disabling that.

Hello Rafael,

Thanks for the link, that is an interesting point I was not aware of, but I am afraid this is not the root cause of my issue. I tried recommendations of this text and there is no significant improvement (well it has been compiling/linking for more than 40 minutes up to now and it is still going on...)

Reading the text at link http://processors.wiki.ti.com/index.php/C%2B%2B_Template_Instantiation_Issues makes me feel that even if most of the time is spent during the linking phase, it is actually the compiling process that is so long because the linker looks calling the compiler for template instantiation (I can also see that compiler warning messages appears during linking, which tends to confirm that). Even during linking, it is the process cmp6x.exe that is running so long (by the way, what is this process used for?)

Would you have other thoughts about things I could try for helping the compiler doing a faster job?

Thanks

Franck

From the clues you have provided, I believe you are correct in surmising that the time is actually spent during recompilation for template instantiation.  The executable cmp6x is responsible only for compacting the assembly instructions, and should not be such a large share of the execution time.  There are a few known problems with compilation time for that executable, but they are not known to be quite as bad as you have described.

Please try using the --no_compress compiler option.  Your code size will go up, but cmp6x will not be called, and your link time should drop dramatically.

We would be very eager to get a test case demonstrating this severe slowdown so that we can fix it.

Wow, that is a 5x improvement disabling compression. Aside having a larger code size, does it have negative impacts on execution speed/performance?

Also, another interesting observation. I am quite new with C++ template usage, but reading some texts on that subject and playing with TI compiler options, I came to those conclusions:

- If I enable the "--static_template_instantiation" option in the compiler, all templates are instantiated during compile time which require all template declarations AND definitions to be located in the .hpp file. In that case, the linker will not request any further instantiation at link time.

- If I disable the "--static_template_instantiation option, no template looks being instantiated before the link time. In that case, the compile phase time looks shorter but actually link time is increased...

I tested both ways for my app. I would expect both ways giving equivalent build times. But surprisingly, enabling the "--static_template_instantiation" option actually gives my another 2x improvement on build time. Is there a logical explanation for that or am I missing something?

Thanks

Franck

When you use --static_template_instantiation, each template entity (function or data) is instantiated, on the first compile, with the required types.  Further, such entities are static in scope, i.e. they can only be accessed from within that file.  The advantage is that there are no recompiles at link time, and build time can be reduced.  The disadvantage is wasted code and data space.  If, in 2 different files, you instantiate my_template<int>, then you have 2 identical copies of whatever my_template is.  If this happens in many different files, or my_template is a lot of stuff, that can add up fast.

Thanks and regards,

-George 

Thanks George for the clarification, that is an important point and I had not understood that from the compiler user guide.

Archaeologist,

I have sent you a test case in a private conversation session so you can reproduce the issue. Let me know if anything is missing.

In the meantime, I would appreciate if you can confirm what are the impacts of disabling compression. Is it only a matter of the output code size, or does it have some impacts on execution speed/performance?

Thanks

Franck

Thank you for the test case.  I am able to reproduce the problem.  This is now SDSCM00041470.

Disabling compression can have an effect on performance due to the cache.  If an application has a larger code footprint, the caches might suffer reduced performance due to capacity and conflict misses.