We are using visual studio to build our applications. Our biggest concern is link time especially for debug target. I list bellow what we tried to minimized link time and what were the gain. If you have others suggestions, reply to my post.

Note that I post a suggestion on “Microsoft Connect” titled “Optimize link time in real developers environment”, feel free to vote for it at : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=511300&wa=wsignin1.0

1 – Convert many statics libraries to DLLs. Important gain.

2 – Remove debug information for libraries who are rarely debugged (good gain).

3 – Delete PDB file in « Pre-Build Event » (strangely it give interesting gain ex: 2min44 instead of 3min34).

4 – Working with computer equiped with lot of RAM in order to maximize disk cache. The biggest gain. Same computer can link 20 times faster with 16GB instead of 2GB. More than 16GB change nothing.

5 – Big obj versus small obj. No difference.

6 – Use secret linker switch /expectedoutputsize:120000000. Small gain.

7 – Maximize Internal linkage vs External linkage. It’s a good programming practice.

8 – IncrediLink (IncrediBuild give interesting gain for compilation but almost no gain for link).

9 – Explicit template instantiation to reduce code bloat. Small gain.

10 – Partial template specialization to decrease the number of symbols. Small gain.

11 – Change project options (/Ob1, /INCREMENTAL, Enable COMDAT folding, Embedding manifest, etc.). Some give interesting gain other not. We try to continuously maximize our settings.

12 – Separate software component as much as we can afford to minimize dependencies. You can then work in unit test that link fast. But we still have to integrate things together, we have legacy code and we worked with third party components.

Note that for all our experimentations, we meticulously measured link time to ensure repeatability.

Thanks

Original post:

http://www.codeproject.com/Messages/3300274/Re-Minimized-link-time-of-Cplusplus-applications.aspx

https://connect.microsoft.com/VisualStudio/feedback/details/511300/optimize-link-time-in-real-developers-environment

As far as distributed PC-Lint runs, I’m curious if you’re doing a file-by-file analysis or generating LOB files for an inter-module analysis. I have personally found that an inter-module analysis is really necessary for taking advantage of PC-Lint’s strengths (inter-function value tracking, etc) to find deep bugs.

The IncrediBuild integration currently supports either single file or whole project analysis (the latter of which will run one project per core of course, so it’s only really worth doing if you have a lot of projects). FWIW the value tracking in PC-lint 9.0 is much improved over 8.0, and even a single file analysis can offer far more information on potential defects than most teams seem able to deal with (nobody likes bad news, right?). That’s a shame, as it’s capable of so much more.

LOB files do indeed offer a way to do detailed inter-module tracking which is not available in other modes (as does whole project analysis, of course). We’ve not yet implemented support for LOBs in Visual Lint as none of our customers have asked for it (something which surprised me, quite frankly. By contrast whole project analysis was much requested from the outset). If any of our customers wants full LOB file support badly enough we’ll happily implement it.

I’m not sure about the answer to your disk bottleneck question – the only way to be sure for real is to try it. I suspect either will bring a great improvement over a typical configuration, though. If you’re looking into performance PC-lint 9.0 precompiled header file support is worth looking into once it’s mature as it can dramatically reduce analysis times. However, as our tests in 9.00a through 9.00c show additional messages are being produced when PCH is enabled, we’ve held off full support for it until that’s resolved.

As far as distributed PC-Lint runs, I’m curious if you’re doing a file-by-file analysis or generating LOB files for an inter-module analysis. I have personally found that an inter-module analysis is really necessary for taking advantage of PC-Lint’s strengths (inter-function value tracking, etc) to find deep bugs.

As far as disk-related bottlenecks, I have a question: would it be better to get a single 15K RPM disk or two 10K RPM disks in a SATA2 RAID configuration? I’m trying to figure out if the elevator seeking would outperform the single spindle, even if it’s slower.

A a bonus, PC-lint is also (as our experience bears out) rather amenable to parallelisation to speed up the analysis runs (we were able to cut the analysis time for our 180k LOC codebase from over 4 hours to 15 minutes or so using IncrediBuild with 6 agents).

We’ve also found that refactoring a codebase for unit testing will naturally reduce include dependencies and hence compilation time. Michael Feathers’ “Working Effectively with Legacy Code” is an excellent guide to the techniques you need to do this.

A final plug: IncludeManager by Profactor Software (http://www.profactor.co.uk/includemanager.php) is a great way to visualise (in graphical form) the includes (and corresponding build time impact) for a given file or project so you can see what’s going on. We use it extensively, and it’s proved absolutely invaluable.

I have a RAID 1 harddisk for robustness. What would be the best way to add another drive (or 2) to speed up compile times – RAID X (what would X be?).

Also, #define WIN32_LEAN_AND_MEAN (for pre-vista SDKs), precompiled headers, and “#pragma once” instead of old-school include guards can also help a lot.

I don’t remember what I used to measure exactly. I think I just downloaded a LOC counting add-on for Visual Studio.