MAP file analysis - where's my code size comes from?

Question

I am looking for a tool to simplify analysing a linker map file for a large C++ project (VC6).

During maintenance, the binaries grow steadily and I want to figure out where it comes from. I suspect some overzealeous template expansion in a library shared between different DLL's, but just browsing the map file doesn't give good clues.

Any suggestions?

Skell

Answer 1

This is a wonderful compiler generated map file analysis/explorer/viewer tool. Check if you can explore gcc generated map file.

amap : A tool to analyze .MAP files produced by 32-bit Visual Studio compiler and report the amount of memory being used by data and code. This app can also read and analyze MAP files produced by the Xbox360, Wii, and PS3 compilers.

Mertens

Thanks for the reply - mroe or less what I was looking for :) – Skell

It's definitely useful. I just wonder, why this is not open-source and somewhere in a public git repository... – Precast

Answer 2

The map file should have the size of each section, you can write a quick tool to sort symbols by this size. There's also a command line tool that comes with MSVC (undname.exe) which you can use to demangle the symbols.

Once you have the symbols sorted by size, you can generate this weekly or daily as you like and compare how the size of each symbol has changed over time.

The map file alone from any single build may not tell much, but a historical report of compiled map files can tell you quite a bit.

Pylos

Answer 3

Have you tried using dumpbin.exe on your .obj files?

Stuff to look for:

• Using a lot of STL?
• A lot of c++ classes with inline methods?
• A lot of constants?

If anything of the above applies to you. Check if they have a wide visibility, i.e. if they are used/seen in large parts of your application.

Flyweight

Answer 4

No suggestion for a tool, but a guess as to a possible cause: do you have incremental linking enabled? This can cause expansion during subsequent builds...

The linker will strip unused symbols if you're compiling with /opt:ref, so if you're using that and not using incremental linking, I would expect expansion of the binaries to be only a result of actual new code being added. That's as far as I know... hope it helps a little.

Drees

/opt:ref is enabled, incremental linking disabled for the release build (which is affected.) But yeah, that are the first things to check – Skell

Answer 5

LinkerScope is a python program for this specific purpose. It generates SVG memory map diagrams directly from GNU's linker .map files, or you can specify several memory regions and do your custom memory maps.

Disclaimer: i'm the author.

Johnnyjumpup

Answer 6

Templates, macros, STL in general all use a tremendous amount of space. Heralded as a great universal library, BOOST adds much space to projects. BOOST_FOR_EACH is an example of this. Its hundreds of lines of templated code, which could simply be avoided by writing a proper loop handle, which is in general only a few more key strokes.

Get Visual AssistX to save typing, not using templates. Also consider owning the code you use. Macros and inline function expansion are not necessarily going to show up.

Also, if you can, move away from DLL architecture to statically linking everything into one executable which runs in different "modes". There is absolutely nothing wrong with using the same executable image as many times as you want just passing in a different command line parameter depending on what you want it to do.

DLL's are the worst culprit for wasting space and slowing down the running time of a project. People think they are space savers, when in fact they tend to have the opposite effect, sometimes increasing project size by ten times! Plus they increase swapping. Use fixed code sections (no relocation section) for performance.

Argilliferous