Inspecting Visual C++ exe size

Started by
5 comments, last by harveypekar 12 years, 4 months ago
Hey everyone,

I want to reduce my exe size. My project pulls in a large lib (LLVM). Before I start amputating at random, I would like to have an idea what takes up the most space. Is there any tool/script that can get some meaningful numbers for me? I know I can generate a .MAP file, but it can't seem to relate it to footprint.

EDIT
already got it
http://aras-p.info/projSizer.html
http://code.google.com/p/mapfile/
Advertisement
Try: http://codesuppository.blogspot.com/2010/03/mapfile-tool-to-analyze-map-files.html

Or for an alternate approach to shrinking the exe: http://upx.sourceforge.net/
Alternatively - don't bother. The days of exe size being any kind of meaningful metric are far far behind us.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

I have found SymbolSort (http://gameangst.com/?p=320) using COMDAT dump much more accurate than projSizer or analyzing map files. It also works with GCC!

One thing to check in Visual Studio is "Enable Function-Level Linking" under "Code Generation" for C/C++ category (it should say Yes). And also "References" and "Enable COMDAT Folding" under Linker->Optimization (both should be Yes). These settings will allow linker to throw out functions from executable that are never called.

Alternatively - don't bother. The days of exe size being any kind of meaningful metric are far far behind us.


The difference in startup can be 0.5 second vs. 15 seconds, depending on many factors, even for small sizes under 10MB.

Due to increased difference between IO and CPU, layout of exe determines the order in which code and data is paged into memory, resulting in huge variations in startup time, simply due to number of IO ops as well as random seeks (SSDs do not solve this problem, merely alleviate it).

For console applications, startup time is a factor. It's what has prevented Java from being useful in such context, since loading JVM could take 10+ seconds.

Firefox is constantly being blasted for having slow startup time, something which Chrome addressed much better.

1 second boot to Qt app.
Link time reordering.

Just like with everything these days, latency, bandwidth and granularity matter a lot. And as with all optimizations, a first good step is to reduce the amount of data one works with, so reducing size of executable, if possible, helps.

Alternatively - don't bother. The days of exe size being any kind of meaningful metric are far far behind us.


exe size may not matter on the desktop but it matters everywhere else, and everywhere else is increasingly important.
Thanks guys, you remind me of why this forum is awesome.

@jewzorek You're absolutely right, in the end this will be run on a mobile device, so space is critical. I just wanted to inspect so I can see where stuff is going.

Exe size sometimes does sometimes matter on desktop though, sometimes you want smaller instructions, as it will run faster than less arithmetic due to the instruction cache not being trashed. Loosely related to global exe size (only matters in hot loops though).

This topic is closed to new replies.

Advertisement