Profiling DLL / LIB Bloat

Question

I inherited a rather large C ++ project in VS2005 that compiles in a DLL of about 5 MB. I would like to reduce the size of the library so that it loads faster on the network for clients who use it from a slow network resource.

I know how to do this by analyzing the code and includes the project parameters, but I wonder if there are any tools that could make it easier to determine which parts of the code consume the most space. Is there a way to generate a “profile” of a DLL layout? Report on what consumes space in the library image and how much?

Answer 1

When you create your DLL, you can pass / MAP to the linker so that it generates a map file containing the addresses of all the characters in the resulting image. You may have to do some scripting to calculate the size of each character.

Using the "strings" utility to scan your DLL may reveal unexpected or unused lines for printing (for example, resources, RCS identifiers, __FILE__ macros, debugging messages, claims, etc.).

Also, if you are not compiling / Os yet, it is worth a try.

Answer 2

If your ultimate goal is only to cut the size of the DLL, then after setting the compiler options you are likely to get the fastest results by running your DLL through UPX . UPX is an excellent compression utility for DLL and EXE; it is also open source with a non-virus license, so it can be used in commercial / closed sources.

I only got a virus warning at the highest compression setting (brute force option), so you'll probably be fine if you use a lower setting than this.

Answer 3

As long as I don’t know about any binary-sized profilers, you can also search which object files (.obj) are the largest, which gives you at least an idea of ​​where your problem spots are. Of course, this requires a fairly modular design.

Answer 4

You can also try linking statically instead of using dll. Indeed, when the library is statically linked, the linker removes all unused functions from the final exe. Once upon a time the last exe is a bit bigger and you no longer have the dll.

Answer 5

If your DLL is large because it exports a C ++ function with exceptionally long garbled names, an alternative is to use a .DEF file to export functions in order without a name (using NONAME in a .DEF file), a bit fragile, but it reduces the size of the DLL , exe size and load time.

See http://home.hiwaay.net/~georgech/WhitePapers/Exporting/Exp.htm

Answer 6

Given that all your .obj files are the same size, assuming you're using precompiled headers, try creating an empty obj file and see how big it is. This will give you an idea of ​​the proportion of each .obj, which is due to the compilation of PCH. By the way, the linker will be able to remove all duplicates. Alternatively, you can try disabling PCH so that obj files provide you with a better idea of ​​where the main culprits are.

Answer 7

All good offers. What I am doing is getting a map file and then just looking at it. What I found in the past is that most of the space is taken up by one or more class libraries, caused by the fact that some variable was somewhere declared as having a type that sounded like it would save some coding but really wasn’t necessary.

Like in MFC (remember that?) They have a wrapper class to get around all the things like controls, fonts, etc. that Win32 provides. They occupy a ton of space, and you do not always need them.

Another thing that can take up a ton of space is collection classes that you could get along with. Another is the cout I / O routines that you are not using.

Answer 8

I would recommend one of the following:

reach - you can run a coverage tool hoping to detect any dead code

caching - client-side dll caching upon initial activation

splitting - split the dll into several smaller DLLs, start the application using the bootstrap dll and load other DLLs after the application starts

compilation and binding - use a smaller runtime library, compile with size optimization, etc. See the link for more offers.

compression If you have data or large resources in a DLL, you can compress and decompress it only after loading or at runtime.