pouët.net

Go to bottom

size-optimizing a sloppily written large binary

category: general [glöplog]
 
Hey, just got this crazy idea, wanted to hear what others think,

if one was to write your own "debugger" (a program that registers as such) that looks for unused code and fill that with zeroes in the binary - would make a smaller executable or dll when packing it...

Of course this doesn't apply for 4k or 64k stuff, because those are size-optimized in code already. But for us other lazy bums that write code with STL and templates and whatnot... And in general for one-purpouse code.

If you make multiple demos with the same engine code, not all demos make use of the entire engine..
added on the 2009-09-02 13:46:09 by jaw jaw
There is a tool for that. Its called "strip".
added on the 2009-09-02 13:48:22 by xeron xeron
is that really what strip does? I thought it just removed symbols... I mean you would have to run the program, strip can't predict how jumps are done when running the program... i.e. code not ever jumped to will never be run: hence you might as well fill it with zeroes...
added on the 2009-09-02 13:52:00 by jaw jaw
it's called code coverage. google it!
added on the 2009-09-02 13:56:01 by rmeht rmeht
ah great, thanks!
added on the 2009-09-02 13:58:32 by jaw jaw
In case you've got source-code polyspace might help you.
added on the 2009-09-02 14:13:10 by hfr hfr
fr had a similar tool like that i think
added on the 2009-09-02 14:15:34 by Gargaj Gargaj
sounds complicated. how are you sure that your run really covers all possibly-executed lines of code? you'd get a really nasty crash if you do this and a user does something exceptional that you didn't bother (or think of) simulating when you ran your debugger-tool..

i guess it'd only work for stuff like demos where every run is the same every time.
added on the 2009-09-02 14:51:56 by skrebbel skrebbel
demo without jumptables
added on the 2009-09-02 15:03:13 by the_Ye-Ti the_Ye-Ti
skrebbel: yes, I only imagined it for demos and other one-way-to-run presentations..
added on the 2009-09-02 15:11:52 by jaw jaw
hfr: gcov in the gcc suite does this (I found out), along with gprof for timing, then ggcov for a graphical interpretation of it
added on the 2009-09-02 15:12:54 by jaw jaw
Quote:
sounds complicated. how are you sure that your run really covers all possibly-executed lines of code? you'd get a really nasty crash if you do this and a user does something exceptional that you didn't bother (or think of) simulating when you ran your debugger-tool..


alternatively, you can use your map/pdb-file to take the blank regions' addresses and translate them back to locations inside your source, so you would have a nice instrumented display of what lines of your source are used.
added on the 2009-09-02 17:04:10 by Gargaj Gargaj
Quote:
fr had a similar tool like that i think

we had a one-shot tool for kkrieger ("lekktor") that did this at source level.

Quote:
sounds complicated. how are you sure that your run really covers all possibly-executed lines of code? you'd get a really nasty crash if you do this and a user does something exceptional that you didn't bother (or think of) simulating when you ran your debugger-tool..

ever wondered why cursor-down doesn't work in the kkrieger pause menu? or why you don't take damage when shot by enemies? or why the enemies get stuck so easily? or why the shadows don't work on cards without two-sided stencil even though the code is basically there?

we had the option to turn this analysis of for certain code regions, but we forgot some codepaths (like the shadow stuff) and then chaos was a bit sloppy in his last recorded run that we used to build the compo version from (and we wondered about it suddenly being 1k smaller...).
added on the 2009-09-02 17:17:27 by ryg ryg
didn't some of the newer version of visual studio provide this? optimize code based on test runs?
profile-guided optimization, yes, but that's only to decide which loops to unroll and which branches to predict as likely/unlikely, not to remove code that might theoretically get called but never actually does with a given dataset :)
added on the 2009-09-02 20:10:19 by ryg ryg
ryg, hah :-) nice one :-)
added on the 2009-09-02 20:17:07 by skrebbel skrebbel

login

Go to top