Quote: "Diggsey beat me to mentioning error line numbers... imagine your program threw an error on line 2567 and you did not have a readable compiled version so in your commented code that line might actually be line 8766..."
As indicated in the original post, this could be taken care of by saving the line number of each command and bringing the output code to the according form after optimization.
On top of that, a release-version should not contain any DBP-errors in the first place - I mean, don't you usually turn DBP-error-checking off for release versions? (so the program will run much faster, but errors, in case they still do exist (which is to avoid) result in a windows-error)
This kind of optimization is
not meant to be used for Beta-Versions or debugging of any shape or form. It is just one rather "brutal" way to gain maximum performance.
Edit: To give you a more practical example what such a program could be used for. Consider the case that your code contains many coloring-operations and you always write them in HEX-form in your code (e.g. "ink 0x80FF0000,0" or just "myColor = 0xFFFFFFFF" or whatever). Maybe those color-HEX-values are used so extensively that they are responsible for 10% for the program's runtime.
Now, as said before, at least in my current version of the DBP compiler hex-values are much slower than integer-values when used as constant in the code. So the optimization-program would just replace "0xFFFFFFFF" by "4294967295" which is the decimal equivalent, resulting in the program running maybe 8% faster than before.
Another example would be getter and setter-functions when working with large chunks of data.
I came across a somewhat similar case: when manipulating images using memblocks, to access each pixel I usually do something like this:
for y = 0 to height
for x = 0 to width
p = GetMemPos(x,y,width)
write memblock dword myMemblock, p, someColor
next x
next y
function GetMemPos(x,y,w)
p = 12 + 4*(x + w*y)
endfunction p
This implementation would be slower than necessary due to the overhead generated by the GetMemPos()-function (putting parameters and result on a stack and all that, or however functions work internally), and a program that optimizes the code and tries to inline simple functions as this one would increase the program's performance significantly while still allowing you to keep this modular coding-style.
The output after running the optimization program could look like this:
for y = 0 to height
for x = 0 to width
write memblock dword myMemblock, 12+4*(x+width*y), someColor
next x
next y
The function call is removed and so is the variable p which generated overhead without actually doing anything useful.
