Visual Studio and .NET Framework Home
Slow link on vc2005, > 10 times slower than vc6
as Not Reproducible
10/19/2006 2:42:35 AM
User(s) can reproduce this bug
We have been using VC6 for a very long time for our 1M line program.
When vc7 became available we ported the code to this platform. After sitting back and waiting for 5 minute links for a couple of months we went back to vc6 with a sob. The reason was the /PDBTYPE:SEPT being removed.
Now that vc8 is available we again ported all of our code up, an effort that has taken about a manmonth so far. We had seen some posts on MSDN where Microsoft people indicated that slow linking on vc7 was a concern, so we had some hopes that the bubble sort causing all this was being replaced...
All to be faced with what is now a 9 minute link time.
It is becoming increasingly impossible to go back to vc6 again as we also link third party libraries and want to use recent platform SDK calls. Also the pdb file size of 64Mbyte hits us hard on this platform.
But nine minutes to link every little code change before being able to test. That means just too much coffee running around our veins in a work day.
The cause for this situation is probably our cleverly design daily-build system which is devised to reduce compile times for our developers. Here's the deal:
All statically linked, native C++ code.
The program is subdivided into about 80 libraries, each with their own sln files. Maybe 20 cpp files average per lib.
These are built by an automated script on a special machine dedicated for the task. The output is a pdb and a lib file for each library.
These files get packed into a zip file along with the corresponding header files of the same versions and pushed to a server.
When a developer wants to upgrade his baseline he executes a script which unzipps all the libs and headers to the local environment.
Now it is possible to rebuild a single lib that has been changed locally and then easily link the entire application. This used to take around 40 seconds on vc6, which was acceptable if not swift. Now we face more than ten times this.
An important observation is that if we don't generate a pdb file the link time problem goes away. Alas we can't debug our program, which is what we intended to do in the first place...
Obviously we would want you to fix your linker, but as this is unlikely to happen we are at least hoping for some advice at how to reduce the impact. Here are some specific questions:
* Rumors on the internet have it that incremental linking doesn't work if lib files are included. Is this true?
* Would it be beneficial to create just one obj file in each lib by having the build machine create a "stdafx.cpp" which includes all the cpp files of the library?
* Would it be beneficial to lib the libraries together into one large library? If so, how can we modify a single of the original libraries when a developer has changed a file?
* We do run pch files in each (or at least a large part) of the libraries, but the set of include files included by each /Yc is different as we don't want a library to refer to a later library in the build order. Would it help our link times to have the same psh contents for all libraries?
Basically the problem is that we don't understand what aspect of our setup causes the extreme pdb-creation times. note that our build process essentially makes a clean build each time so we don't have lots of old junk laying around in the individual pdb files.
Please help, I don't know what we're going to do if we can't get this operating, we can't stay with vc6 forever!
Visual Studio 2005 Standard Edition
Windows XP Professional
Operating System Language
Steps to Reproduce
Link a large application with many obj files
Link time of 9 minutes
Link time of 40 seconds, as in VC6
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 8/23/2007 at 10:01 AM
Have a very similar situation, and can confirm that Service Pack 1 does not solve the issue with long linking times when having several libraries with lots of code.
The patch so far is to use Fast Solution Build (Or Incredilink), so the dependency checking while linking is disabled. This solves the issue of incremental linking not working when modifying a library.
Guess one should not use libraries but DLL's when using VS 2005.
on 12/4/2006 at 11:59 AM
Thanks for the report.
Unfortunately we are unable to proceed with this issue without having a test case which reproduces the issue.
You can make such a test case by using the linker to generate the set of objects and other files required to reproduce this problem.
To do so, create a directory, e.g. c:\lr, and then set LINK_REPRO to c:\lr, e.g.:
and then do whatever you need to to link *just this one piece of code* (this is important).
Afterward, the c:\lr directory should be populated with the files required to link this. There should be a file, link.rsp in that directory. Please confirm that you can reproduce this behavior by first clearing LINK_REPRO, and then going to c:\lr and doing:
If you're able to reproduce this issue there, please zip the files in c:\lr, reactivate this issue, and attach the test case.
on 11/8/2006 at 4:10 PM
Are you using /Z7 or /Zi for your compiles?
It is very hard to know where the time is being spent without a test case with your object files, compile-time PDBs, and PCH.
to post a workaround.
Please enter a workaround.
© 2013 Microsoft