- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there
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).
Cheers
Jon
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).
Cheers
Jon
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
For rapid development cycles you would probably disable global interprocedural optimization (IPO), although you didn't say anything about that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there
Yes it's 64 bit Windows 7 Home Premium , and I download the Product for 32-bit/64-bit (x64) development, should I have just downloaded the 64 bit version only ?
About IPO, I've tried with it single file, multi file & off, doesn't seem to help.
Cheers
Jon
Yes it's 64 bit Windows 7 Home Premium , and I download the Product for 32-bit/64-bit (x64) development, should I have just downloaded the 64 bit version only ?
About IPO, I've tried with it single file, multi file & off, doesn't seem to help.
Cheers
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there
Ok, I'll try re-installing, specifically the 64 bit version and see what happens.
Cheers
Jon
Ok, I'll try re-installing, specifically the 64 bit version and see what happens.
Cheers
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Cheers
Jon
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.
Cheers
Jon

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page