How to improve link performance for a large C++ application in VS2005

Question

We have fairly large C++ application which is composed of about 60 projects in Visual Studio 2005. It currently takes 7 minutes to link in Release mode and I would like to try to reduce the time. Are there any tips for improving the link time?

Most of the projects compile to static libraries, this makes testing easier since each one also has a set of associated unit tests. 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.

Would using DLLs for the sub projects make any difference? I don't really want to go through all the headers and add macros to export the symbols (even using a script) but if it would do something to reduce the 7 minute link time I will certainly consider it.

For some reason using nmake from the command line is slightly faster and linking the same application on Linux (with GCC) is much faster.

• Visual Studio IDE 7 minutes
• Visual C++ using nmake from the command line - 5 minutes
• GCC on Linux 34 seconds

Answer 1

If you're using the /GL flag to enable Whole Program Optimization (WPO) or the /LTCG flag to enable Link Time Code Generation, turning them off will improve link times significantly, at the expense of some optimizations.

Also, if you're using the /Z7 flag to put debug symbols in the .obj files, your static libraries are probably huge. Using /Zi to create separate .pdb files might help if it prevents the linker from reading all of the debug symbols from disk. I'm not sure if it actually does help because I have not benchmarked it.

Answer 2

See my suggestion made at Microsoft : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=511300

You should vote for it ! Here is my last comment on it :

Yes we are using incremental linking to build most of our projects. For the biggest projects, it's useless. In fact, it takes more time to link those projects with incremental linking (2min50 compared to 2min44). We observed that it doesn't work when size of ILK files is big (our biggest project generate an ilk of 262144 KB in win 32).

Bellow, I list others things we tried to reduce link time:

• Explicit template instantiation to reduce code bloat. Small gain.
• IncrediLink (IncrediBuild give interesting gain for compilation but almost no gain for link).
• Remove debug information for libraries who are rarely debugged (good gain).
• Delete PDB file in « Pre-Build Event » (strangely it give interesting gain ex: 2min44 instead of 3min34).
• Convert many statics library to DLL. Important gain.
• Working with computer equiped with lot of RAM in order to maximize disk cache. The biggest gain.
• Big obj versus small obj. No difference.
• Change project options (/Ob1, /INCREMENTAL, Enable COMDAT folding, Embedding manifest, etc.). Some give interesting gain other not. We try to continuously maximize our settings.
• Maximize Internal linkage vs External linkage. It's a good programming practice.
• Separate software component as much as we can afford. You can than work in unit test that link fast. But we still have to interate things together, we have legacy code and we worked with third party component.
• Use secret linker switch /expectedoutputsize:120000000. Small gain.

Note that for all our experimentation, we meticulously measured link time. Slow link time seriously cost in productivity. When you implement complex algorithm or track difficult bug, you want to iterate rapidly this sequence : modify some code, link, trace debug, modify some code, link, etc...

Another point to optimize link time is the impact it have on our continuous integration cycle. We have many applications that shared common code and we are running continuous integration on it. Link time of all our applications took half the cycle time (15 minutes)...

In thread https://blogs.msdn.microsoft.com/vcblog/2009/09/10/linker-throughput/, some interesting suggestions were made to improve link time. On a 64 bits computer, why not offering an option to work with file completely in RAM ?

Again, any suggestions that may help us reduce link time is welcome.

Answer 3

Generally, using DLLs instead of static libraries will improve linking times quite a bit.