This is a bit of a dumb question, but I thought I’d ask it, to get it clear in my mind.
Being an old-skool kinda programmer, I tend to declare all my variables for any particular function at the top of the function, like so:
void FunctionTest ( float Timer )
{
int i, j, k;
float Hello;
[i]etc[/i]
[i]...code goes here...[/i]
}
Then I do any tests which might result in the function not being executed, like:
if ( Timer > 5.0f )
return;
does the fact that I allocate these variables before doing the null execution test actually take processor cycles? In other words, if I did the (Timer > 5.0f) test prior to the declaration of the variables, would the code run faster, if this function is used a lot of times?
These kind of micro optimizations will virtually never have any measurable effect on your frame rate, so do not worry about it. Optimization is about measuring the most expensive elements of your game and then improving those specific elements. Optimization without measuring first rarely pays off and is often hurtful (as optimization often makes code more complex).
I agree with tomvds, either way, it’s not going to be an issue, and don’t start optimizing unless A) It’s too slow already B) You’ve measured out a particular culprit that requires optimization.
But in addition, especially when using a managed language like C# (or any of the .NET languages), many of these choices are not even yours to make. The .NET (JIT and AOT) compiler can rearrange declaration locations, inline functions, and do all sorts of micro optimizations for you. .NET handles many micro-optimizations and will not be guaranteed to compile the exact same way it was written. This can be somewhat of a blessing and a curse, but is part of the managed element of a managed language.
As an extreme example, create a coroutine, and then look at the outputted code using an application like ILSpy. The code after processing is entirely unlike the code you wrote. (Not an optimization, but a good example of .NET rewriting your code into an entirely different form). Your single function becomes an entire class, with switch blocks and unusual variable declaration locations (to help keep a concept of function scoped variables without having to put them on the stack).
Thanks, chaps - just desperate to find every last ms of performance I can!
I have noticed that I do get different results when I build the game sometimes - from changes that I’ve made which shouldn’t actually affect the game as they do - is this due to the randomness of how the JIT compiler works?
It used to be, in C (when it finally supported the ability) and C++, your variable was generally** declared at or around the point your declared it. I am of the “old school” thought that variables go at the top**** of the function but slowly my style has evolved whereby I put the variable declaration closer to where they are first used if it makes sense. I go with what “looks artistically acceptable” to be rather than any hard and fast rule of precise placement of variable declarations because frankly, that’s just a religious war that isn’t worth getting in to; I am sure the disagreeable and disgusting wannabe water buffalo with the big teeth and no worthy contribution to the discussion wants to make who is clearly wrong about any opinion on this subject will agree with.***
.NET is also in the habit of just “doing it’s own thing” when it comes to variable declarations, so sticking them at the top won’t make that much difference to compiler when it thinks “I can optimise here by moving it closer to the variable usage.”
Also, I am with tomvds on this. Worry about the micro-optimisations when it is time to worry about them.
** assuming your compiler didn’t do some nefarious optimisations you weren’t aware of.
*** Told you it was a religious war.
**** We are talking about variable function declarations here, right? People that put variables halfway down in a class file that extends for a thousand lines of code need to be taken out behind the woodshed.
Edit: I am obviously not very coherent this morning. crosses eyes