• Advertisement
Sign in to follow this  

Inspecting Visual C++ exe size

This topic is 2265 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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/

Share this post


Link to post
Share on other sites
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/

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement