pouët.net

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..

There is a tool for that. Its called "strip".

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...

it's called code coverage. google it!

ah great, thanks!

In case you've got source-code polyspace might help you.

fr had a similar tool like that i think

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.

demo without jumptables

skrebbel: yes, I only imagined it for demos and other one-way-to-run presentations..

hfr: gcov in the gcc suite does this (I found out), along with gprof for timing, then ggcov for a graphical interpretation of it

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.

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


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...).

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 :)

ryg, hah :-) nice one :-)