How to increase link speed for a large c++ dll in VS 2005?
I have to support a quite large C++ application (win dll). I use MS Visual Studio 2005 as IDE.
The app is structured (under VS 2005) as a solution with 7 o 8 projects and about 400 files (200 .h or .hpp and 200 .cpp).
A full rebuild in release mode takes around 5 minutes to compile and 15 minutes to link (in an Intel Core2 Duo PC with 2GB RAM).
So reducing linking time is desirable. Are there any tips for improving the link time?
Even more annoying is that the same slowness happens in debug mode (also in link time).
The size of the release dll is around 11 MB (20 MB debug dll).
All this slow linking started to happen when I upgraded VS from 2003 to 2005. With VC++ 2003, a full release rebuild use to take less than 10 minutes.
I am using precompiled headers (pch). Most of the code is written as c++ templates.
Most of the projects compile to static libraries. It seems the use of static libraries prevents VS2005 from using incremental linking, so even with incremental linking turned on it does a full link every time.
Any idea to reduce linking time?
The app is structured (under VS 2005) as a solution with 7 o 8 projects and about 400 files (200 .h or .hpp and 200 .cpp).
A full rebuild in release mode takes around 5 minutes to compile and 15 minutes to link (in an Intel Core2 Duo PC with 2GB RAM).
So reducing linking time is desirable. Are there any tips for improving the link time?
Even more annoying is that the same slowness happens in debug mode (also in link time).
The size of the release dll is around 11 MB (20 MB debug dll).
All this slow linking started to happen when I upgraded VS from 2003 to 2005. With VC++ 2003, a full release rebuild use to take less than 10 minutes.
I am using precompiled headers (pch). Most of the code is written as c++ templates.
Most of the projects compile to static libraries. It seems the use of static libraries prevents VS2005 from using incremental linking, so even with incremental linking turned on it does a full link every time.
Any idea to reduce linking time?
Please refer this link, may be it is useful,
http://stackoverflow.com/questions/143808/how-to-improve-link-performance-for-a-large-c-application-in-vs2005
http://stackoverflow.com/questions/143808/how-to-improve-link-performance-for-a-large-c-application-in-vs2005
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can you down grade back to VS2003 or upgrade your computer?
I know that seems like sort of a silly response, but I'm not suprized that a Microsoft UPGRADE results in a DOWNGRADE in performance. From what I've seen, MS is all about features, and lets advancements in hardware take care of "performance issues". (Haven't you heard the phrase "What Intel Giveth, Microsoft Taketh?).
But seriously, unless there is something you NEED out of VS2005, if the upgrade is what killed your perfomance, then downgrade back until you can upgrade both the hardware and the software is my suggestion.
I know that seems like sort of a silly response, but I'm not suprized that a Microsoft UPGRADE results in a DOWNGRADE in performance. From what I've seen, MS is all about features, and lets advancements in hardware take care of "performance issues". (Haven't you heard the phrase "What Intel Giveth, Microsoft Taketh?).
But seriously, unless there is something you NEED out of VS2005, if the upgrade is what killed your perfomance, then downgrade back until you can upgrade both the hardware and the software is my suggestion.
ASKER
The clue to improve performance has been to check the IO activity. It seems the corporative antivirus is slowing down the writing of temporary files generated both by cl.exe and link.exe. I managed myself to disable the AV and now the full release is taking 15 minutes to build. That is, half time less than before.
Thanks
Thanks
2. Get procmon from sysinternals.com. At the linkage time trace what files are open/read/written. This may give you some clues.