views:

58

answers:

1

Let's say I have a project with a dozen of different modules which produce one resultant DLL, how can I analyze it so that I can identify the actual file size that each module/functions contribute? I know it might be impossible with a Release build where much information has been stripped, but how about if I have the full source and can do a Debug build?

Also, if there are big static variables defined somewhere, is there a way I can easily locate them?

Bonus question: How about Linux ELF files?

+1  A: 

Whenever I've been involved in identifying bloat I generally start with dumpbin on Windows. Usually by writing a tool to examine each object module via dumpbin then analyse the output. It tends to be an iterative process and can take a fair amount of time.

For debug builds with PDB Sizer can produce useful reports.

Adrian has some useful guidance here. Minimizing Code Bloat for Faster Builds and Smaller Executables and a tool called SymbolSort to help. The source in C# is included with SymbolSort so that may be a good place to start if SymbolSort doesn't help.

For ELF the output of nm and objdump are a good starting point.

Richard Harrison
This is absolutely fantastic! They have this stupid 24 hour policy for bounty :P
kizzx2
Just took a look at `nm -S`. What a simple problem that is so obscure to solve on Windows :P
kizzx2