Profiling DLL/LIB Bloat

Question

I\'ve inherited a fairly large C++ project in VS2005 which compiles to a DLL of about 5MB. I\'d like to cut down the size of the library so it loads faster over the network

Answer 1

While i don't know about any binary size profilers, you could alternatively look for what object files (.obj) are the biggest - that gives you at least an idea of where your problematic spots are.
Of course this requires a sufficiently modularized project.

Answer 2

All good suggestions. What I do is get the map file and then just eyeball it. The kind of thing I've found in the past is that a large part of the space is taken by one or more class libraries brought in by the fact that some variable somewhere was declared as having a type that sounded like it would save some coding effort but wasn't really necessary.

Like in MFC (remember that?) they have a wrapper class to go around every thing like controls, fonts, etc. that Win32 provides. Those take a ton of space and you don't always need them.

Another thing that can take a ton of space is collection classes you could manage without. Another is cout I/O routines you don't use.

Answer 3

Given that all your .obj files are about the same size, assuming that you're using precompiled headers, try creating an empty obj file and see how large it is. That will give you an idea of the proportion of each .obj that's due to the PCH compilation. The linker will be able to remove all the duplicates there, incidentally. Alternatively you could try disabling PCH so that the obj files will give you a better indication of where the main culprits are.

Answer 4

When you build your DLL, you can pass /MAP to the linker to have it generate a map file containing the addresses of all symbols in the resulting image. You will probably have to do some scripting to calculate the size of each symbol.

Using a "strings" utility to scan your DLL might reveal unexpected or unused printable strings (e.g. resources, RCS IDs, __FILE__ macros, debugging messages, assertions, etc.).

Also, if you're not already compiling with /Os enabled, it's worth a try.

Answer 5

i would recommend one of the following:

coverage - you can run a coverage tool in the hope of detecting some dead code

caching - cache the dll on the client side on the initial activatio

splitting - split the dll into several smaller dlls, start the application with the bootstrap dll and download the other dlls after the application starts

compilation and linking - use smaller run time library, compile with size optimization, etc. see this link for more suggestions.

compression - if you have data or large resources within the dll, you can compress them and decompress only after the download or at runtime.

Answer 6

You can also try to link statically instead of using a dll. Indeed, when the library is linked statically the linker removes all unused functions from the final exe. Sometime the final exe is only slightly bigger and you don't have any more dll.