1

In our case, the /DEBUG binary is 50% larger, the binary built with /DEBUG /OPT:REF is still 40% larger. From the answers in Visual Studio: debug information in release build I expected a release build with debug information shouldn't be that much larger. What are we missing?

This is one major reason why we're currently shipping the stripped binary, instead of one that's easy to debug. I'm not the build master, so please bear with me.

Sizes:
22MB with /O2
35MB with /O2 /DEBUG
32MB with /O2 /DEBUG /OPT:REF

Community
  • 1
  • 1
Sascha
  • 986
  • 10
  • 30
  • 2
    This does rather fall in the "of course it is larger!" and "why would you care?" category. The code isn't optimized so of course it is larger. You also always want to use the /INCREMENTAL linker option for debug builds to get nice fast link times, but beefy images. Always ship the Release build. – Hans Passant Feb 15 '12 at 13:46
  • I thought the same, until [Michael Burr](http://stackoverflow.com/a/6364789/1210825) proved the opposite. Besides, we're not even running any size-optimization on the release build (without debug info). I wouldn't care for 10 MB either, but my boss takes pride in small binaries. I want to convince him, that a release build with debug info has next to no downside. – Sascha Feb 15 '12 at 20:39

3 Answers3

1

According to the VS2005 documentation at http://msdn.microsoft.com/en-us/library/xe4t6fc1(v=vs.80).aspx:

/DEBUG changes the defaults for the /OPT option from REF to NOREF and from ICF to NOICF (so, you will need to explicitly specify /OPT:REF or /OPT:ICF).

So to reduce the size you can try to specify both:

/O2 /DEBUG /OPT:REF /OPT:ICF
orcy
  • 1,304
  • 14
  • 29
1

If it was written in C++, STD could be complied much larger when not optimized. But I'm not sure if that is the case. How large in bytes exactly is that 50%?

BlueWanderer
  • 2,671
  • 2
  • 21
  • 36
  • When you are compiling without optimizing, no function is automatically inlined(if you have lots of small functions as in STD, inlining will reduce code size), no reference or pointer is aliased, expressions are executed as they are written. Those will produce much more code. – BlueWanderer Feb 16 '12 at 05:32
  • We're using the same optimizing flags as in the release build /O2 and /Ob2. So we're going for speed, not size. – Sascha Feb 16 '12 at 12:35
  • Actually I didn't know /DEBUG would generate different binary... are you compiling in the IDE or in the console? – BlueWanderer Feb 16 '12 at 13:41
  • For comparison we compiled in the IDE, the build is automated with nmake (I think) but I thought there is no difference, if you use the same flags. – Sascha Feb 16 '12 at 22:28
  • Just that it would be weird if one were compiling with /DEBUG flag in the IDE. I believe linking with /DEBUG on and other flags based on a Release Configuration (the default Release configuration has the /DEBUG flags, too) won't produce larger binary. It just generate a .pdb file describes the binary. – BlueWanderer Feb 18 '12 at 08:34
0

Code probably won't product that large binary. Few hints:

  • Are you using Static Library, instead of Dynamic Linking, specifically MFC DLL?
  • Having large set of resources, viz. icons, bitmaps, string resources, custom resources?
Ajay
  • 18,086
  • 12
  • 59
  • 105
  • Afaik were statically linking Qt. I think that makes up roughly 10MB in the release executable without debug info. The C code has about 1.8 Million lines. – Sascha Feb 16 '12 at 12:32
  • I dont use QT, but I believe it wont be that big at binary level. – Ajay Feb 16 '12 at 14:32