tags:

views:

29

answers:

2

I am working to reduce the build time of a large Visual C++ 2008 application. One of the worst bottlenecks appears to be the generation of the PDB file: during the linking stage, mspdbsrv.exe quickly consumes available RAM, and the build machine begins to page constantly.

My current theory is that our PDB files are simply too large. However, I've been unable to find any information on what the "normal" size of a PDB file is. I've taking some rough measurements of one of the DLLs in our application, as follows:

  • CPP files: 34.5 MB, 900k lines
  • Header files: 21 MB, 400k lines
  • Compiled DLL: 33 MB (compiled for debug, not release)
  • PDB: 187 MB

So, the PDB file is roughly 570% the size of the DLL. Can someone with experience with large Visual C++ applications tell me whether these ratios and sizes make sense? Or is there a sign here that we are doing something wrong?

(The largest PDB file in our application is currently 271 MB, for a 47.5 MB DLL. Source code size is harder to measure for that one, though.)

Thanks!

A: 

Yes, .pdb files can be very large - even of the sizes you mention. Since a .pdb file contains data to map source lines to machine code and you compile a lot of code there's a lot of data in the .pdb file and you likely can't do anything with that directly.

One thing you could try is to split your program into smaller parts - DLLs. Each DLL will have its own independent .pdb. However I seriously doubt it will decrease the build time.

sharptooth
Thanks. I do plan to experiment with smaller DLLs; my hope is that this will result in smaller PDB files, which can then be processed in less memory, resulting in less paging and reduced disk I/O. That's just a hypothesis right now, though.
Darryl Shpak
A: 

Do you really need full debug information at all time? You can create a configuration with less debug info in it.

But as sharptooth already said, it is time to refactor and split your program in small more maintainable parts. This won't only reduce build time.

codymanix