4

A DLL I've been working on has recently grown a lot in size. Are there any tools that will tell my what is responsible for this? For instance, is it a template that is being instantiated too many times, or perhaps a 3rd party lib, or maybe boost?

I'm looking for a kind of profiler that looks at size rather than performance.

Pedro d'Aquino
  • 5,130
  • 6
  • 36
  • 46
  • Well, you are the guy building it! Why do you need a profiler to see what you yourself must have added? –  May 17 '11 at 18:12
  • 1
    @Neil Butterworth: I'm trying to see if there's a particularly heavy class, template, or a function that's being inlined too aggressively -- I don't know how to figure that stuff out by inspection. – Pedro d'Aquino May 17 '11 at 18:21
  • 3
    What have you been feeding it? Didn't they tell you no pizza after midnight in the shop? – David Rodríguez - dribeas May 17 '11 at 18:29
  • 2
    Easy. Go back in your version control to when you were happy with the size. Diff then with now. –  May 17 '11 at 18:42

2 Answers2

7

Are you talking about size of the DLL in bytes? Try using the dumpbin utility. This can show you what's inside your DLL. /ARCHIVEMEMBERS should show you the individual object modules.

http://support.microsoft.com/kb/177429

Bill Brasky
  • 2,614
  • 2
  • 19
  • 20
  • ++ Yeah. I either do that, or get a mapfile and see what's in there. Likely as not, it's filled with big chunks of class library put in there because of some variable I declared, that I didn't actually even need. – Mike Dunlavey May 18 '11 at 01:32
3

If your DLL has other dependencies and you are using STATIC linking to link your DLL to them, you can expect your DLL to grow larger:

Static linking vs dynamic linking

  • Static linking can make binaries easier to distribute to diverse user environments (at the cost of sending a large and more resource hungry program).

EDIT:

I found the answers in this thread quite interesting for your problem: Profiling DLL/LIB Bloat

But an interesting experiment would be to verify if for each template instantiation, the resulting executable size grows linearly. If it does, you know your problem is template instantiation. There's a decent article here that talks about this type of problem and presents a technique to refactor it.

EDIT:

There's a big chance that your problem is a consequence of using boost headers. Check this thread to find out why: Why does using boost increase file size so much?

Community
  • 1
  • 1
karlphillip
  • 92,053
  • 36
  • 243
  • 426
  • Unfortunately, distribution to "diverse user environments" is precisely what I have to do. Switching to dynamic linking was my first thought, but that was immediately ruled out for a number of reasons. – Pedro d'Aquino May 17 '11 at 18:24
  • @karlphilip I'm using the header-only parts of boost. – Pedro d'Aquino May 17 '11 at 18:31
  • @Pedro An interesting experiment would be to verify if for each template instantiation, the resulting executable size grows linearly. – karlphillip May 17 '11 at 18:41
  • There's a decent page on The Code Project called *Refactoring Template Bloat*, it might be interesting for you to read if you detect that the problem is really templates instantiation: http://www.codeproject.com/KB/cpp/RefactoringTemplateBloat.aspx?q=c%2b%2b+template+code+bloat – karlphillip May 17 '11 at 18:45