I've updated to a new pc (i7 -2600 , 8 gb memory, 2 tb drive), and in doing so I've update to Visual Studio 2010 and XE 12.1 (I was using VS2005 and XE 11 (iirc) beforehand).
And in this new setup, full compilation time is much much longe. Before it was around 15 minutes, and on my new system which is better in all specs it takes around an hour. using the VS c++ compiler takes around a minute.
I've tried turning off any process on the PC which might cause problems (such as real time virus checks), does help. The CPU usage for the link.exe seems to be around 13% looking in Resource Monitor and there doesn't seem to excess memory usage (at around 3.3 gb , I've ordered another 8 gb of memory to reach 16 gb in case this helps).
I've tried changing the options in the optimizer, all to no avail either.
Putting on verbose in the linker, it reaches this point
1> Discarded '.trace' from libmmt.lib(libm_error.obj)
and then it pauses, in output for around an hour , then outputs
1> 1> Selected symbol: 1> ___init_collate from LIBCMT.lib(initcoll.obj)
before quickly finishing.
Any help with those would be most welcome, because it makes testing & developing much slower (and painful).
Can we assume you're running a Windows X64 and the Intel64 compilers? Those would be requirements to take advantage of additional RAM. For rapid development cycles you would probably disable global interprocedural optimization (IPO), although you didn't say anything about that.
From the installer you chose, you could install either the 32-bit or 64-bit compiler, or both. In past VS versions, you had to select the optional X64 development components under the C++ development option in Visual Studio installation before installing the Intel64 (X64) C++. In VS2010, the C++ option includes both 32- and 64-bit support. I suppose the VS shell would default to the 32-bit version, if you installed that, so you would want to select X64 specifically.
I was suspecting that multi file IPO would slow down your link.
Further to my previous message, I think I've found a fix for now.
After a long period of checking the various flags I tracked it down to the String Pooling flag (/GF), disabling this and disabling the version set by the optimization flag (/O3) with the /Gf flag, and the code compiles in 8 minutes rather than 2 hours (!), the CPU usage seems to be as expected for the optimized version and in general it seems to work without any major problems.
The code I'm using does have rather a lot of text built in, and /Gf as read / write string pooling (rather than /GF as read only string pooling) seems to be considered to be not the best way to do things.
So any suggestions about how I can fix the problem with /GF so I don't have to use the depricated /Gf would be helpful.