Release configuration link times

  • Thread starter Thread starter Paul Cameron
  • Start date Start date
P

Paul Cameron

Hello,

We've recently migrated a very large (40+ projects, 1+ million LOC) VC6
workspace to VC7.1. In general, the compiler and linker are slower. The
worst seems to be the release link; under VC6 it would take 15 minutes to
link the main exe, under VC7.1 it typically takes an hour. Anyone have any
tips on how to diagnose the bottleneck and find workarounds?

This is just one of several severe problems we've encountered in the
migration. I'll post other issues separately. We left VC6 due to size
limitation on the pdb files (64MB) - I wish we would have invested our time
finding ways to further modularize our main exe instead of upgrading to
VC7.1. When we release a new version of our products, our customers expect
them to be more robust and faster - what a concept. Is VC7.1 designed for
large application development or just simple .NET apps? Sorry, just venting
a bit...

Thanks,
Paul
 
--------------------
| From: "Paul Cameron" <paul@mwoffice>
| Subject: Release configuration link times
| Date: Thu, 6 May 2004 12:36:29 -0600

|
| Hello,
|
| We've recently migrated a very large (40+ projects, 1+ million LOC) VC6
| workspace to VC7.1. In general, the compiler and linker are slower. The
| worst seems to be the release link; under VC6 it would take 15 minutes to
| link the main exe, under VC7.1 it typically takes an hour. Anyone have any
| tips on how to diagnose the bottleneck and find workarounds?
|
| This is just one of several severe problems we've encountered in the
| migration. I'll post other issues separately. We left VC6 due to size
| limitation on the pdb files (64MB) - I wish we would have invested our
time
| finding ways to further modularize our main exe instead of upgrading to
| VC7.1. When we release a new version of our products, our customers expect
| them to be more robust and faster - what a concept. Is VC7.1 designed for
| large application development or just simple .NET apps? Sorry, just
venting
| a bit...

Hi Paul,

One of the things you could try is to add /TEST to the linker options and
see if you get any interesting data from that.

Additionally, things to look for include:
* are lots of exports via __declspec(dllexport) being used, especially on
classes in header files?
* is a compiler PCH being used and does it contain most or all of these
classes?
* how big are all the object files being linked in? libraries?
* how much memory in the machine?
* how much memory is the linker consuming?
* how big is the resulting image and PDB file?

This data would be useful. Lastly, constructing a link repro . Here's how
to create a link repro:
(for 6.20 and later linkers)
1. mkdir <some_dir>
2. add /linkrepro:<some_dir> to the linker command line
3. run the offending link command
4. copy any of the compiler generated .pdb files that are necessary.

Lastly, I will be starting a project to collect these linker issues into a
whitepaper, as this has become one of the more common issues we see on the
newsgroup.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager
 
Hi Kang,

Thanks for the response. Here's some of the info you asked for:

- Adding /TEST only seems to add the file (512) and section (4096) alignment
size to the output window.
- I also added /TIME which showed that pass 1 took the vast majority of
time.
- There are not many exports declared
- PCH is used with mainly common CRT, Windows, STL, ATL, and WTL headers
- The main exe has around 1000 obj files that have a total size of about
290MB
- The main exe links against quite a few static libs. About 5 that are 10+
MB, at least 10 more that are <1MB
- Machine has 512 MB RAM, link.exe peeks at 350MB. I suppose it could be
swapping a bit.
- Resulting image is 12.8MB, pdb file is 72 MB
- I noticed CPU utilization was poor - lots of disk activity of course.

I can look at doing the /repro but I suspect this will be a huge pile of
data. How would I get it to you? You can e-mail me direct with instructions
if you'd like. Add ".com" to my e-mail address.

Thanks,
Paul
 
Back
Top