How to determine component memory usage in a big program

[longden_loo]

I have a large legacy program with lots of arrays and obviously lots of code, and the build gives me a warning that the image size "exceeds maximum allowable size".

So I was wondering if there was a tool or option that shows the memory usage (perhaps sorted by usage size) for each variable/array in the program ... so I could focus immediately on the worst offenders? Sometimes it's not obvious which ones are the worst when you have a mixture of multi-dimensional arrays of different element sizes.

I know they used to include this information as part of a normal compilation listing on the old mainframes, but I don't see anything similar. If not part of IVF, is there a 3rd party tool that does an analysis like this?

Also, is there a command in Windows (or IVF) that can tell me the image size of a .exe/.dll ... besides the build warning I get when it's too big?

Thx,
Longden

[Steven_L_Intel1]

The compiler does not have this feature - it has been often requested. You can generate a link map and see which object module contributes most to the image size. I don't know of an easy way to look at an EXE and see how much static allocated memory it has.

[jdchambless]

Steve,

Could you elaborate on how to generate this link map in version 10? I am also having some issues with a program requiring a very large amount of memory, but I can't seem to find out where the sink is.

Thanks,
Jason C.

[Steven_L_Intel1]

Right click on the project, select Properties. Expand the Linker section and click Debug. Change "Generate Map File" to Yes. Build the project.

The map file, which will be projectname.map in the Debug or Release subfolder, will have a section near the beginning that looks similar to this:

Start Length Name Class

0001:00000000 0006b944H .text CODE

0002:00000000 00000190H .idata$5 DATA

0002:000001a0 0000d63cH .rdata DATA

0002:0000d7dc 00000044H .rdata$debug DATA

0002:0000d820 00000004H .rtc$IAA DATA

0002:0000d824 00000004H .rtc$IZZ DATA

0002:0000d828 00000004H .rtc$TAA DATA

0002:0000d82c 00000004H .rtc$TZZ DATA

0002:0000d830 00000028H .idata$2 DATA

0002:0000d858 00000014H .idata$3 DATA

0002:0000d86c 00000190H .idata$4 DATA

0002:0000d9fc 00000710H .idata$6 DATA

0002:0000e10c 00000000H .edata DATA

0003:00000000 00000004H .CRT$XCA DATA

0003:00000004 00000004H .CRT$XCAA DATA

0003:00000008 00000004H .CRT$XCF DATA

0003:0000000c 00000004H .CRT$XCZ DATA

0003:00000010 00000004H .CRT$XIA DATA

0003:00000014 0000000cH .CRT$XIC DATA

0003:00000020 00000004H .CRT$XIZ DATA

0003:00000024 00000004H .CRT$XPA&
nbsp; DATA

0003:00000028 00000004H .CRT$XPX DATA

0003:0000002c 00000004H .CRT$XPZ DATA

0003:00000030 00000004H .CRT$XTA DATA

0003:00000034 00000004H .CRT$XTZ DATA

0003:00000040 00003460H .data DATA

0003:000034a0 0000597cH .bss DATA

0004:00000000 00000058H .trace DATA

0005:00000000 00000030H _RDATA DATA

You are interested primarily in the .data and .bss sections, though .rdata may also be of interest. The rest of the map file shows the individual contributions of the various objects and libraries. Some of it will be the run-time libraries, some your code. It will list the starting address of each contribution, so you have to look at what follows to get an idea of the size of that contribution. It may make your head spin for a while.

None of this helps if the primary problem is dynamically allocated data.