I’ve always felt that .NET should optimize IL, but I have yet to prove that it does. That may be because of the code I’ve looked at…and possibly because I’ve mostly looked at stuff generated by 2010 and earlier, with not so much later.
As for rule #1 of Optimization…geeks are gonna geek, useful or not.
Thanks guys, very interesting stuff!
I am absolutely on board with this (though admittedly some part of me finds optimizing code, prematurely and otherwise, weirdly satisfying).
Even though this thread is full of cool insights I feel like what I actually wanted to know is still half unanswered, so let me put it differently:
// nothing to do
if (_batchItemCount == 0)
return;
When I look at those two lines I see an attempt at optimization. Two lines of code that are only there to make the program run faster in a particular case.
If so, getting rid of those lines would make the code cleaner but less optimized right? Unless those lines are actually examples of early optimization themselves (speeding up an exotic case by an insignificant amount by slowing down a common one by an insignificant amount) because then naturally getting rid of those lines would make the code cleaner and insignificantly faster.
My assumption is of course that those lines have good reason to be there and that I am missing something obvious.
Thanks
It would depend on the code that comes after it. The code could be expensive to run even if there is nothing to render so adding a few instructions would be an optimization. Much less than a millisecond, probably a few nanoseconds, compared to a couple milliseconds is definitely an optimization in a game. Especially when you’re aiming for less than 16 milliseconds per frame.
The code wouldn’t really be any cleaner without them though really as the intent is clear. Without the comment it would be a little more unclean.
In the initial post, you said that the main bulk of the code is inside that While loop. The devil is in the details, though. That loop appears to do essentially the same thing that the If statement does (not quite, the same, but I’d guess that batchCount is _batchItemcount), but as long as that is true, what code is NOT inside the while loop? If that takes longer to run than the conditional, then the conditional is justified.
Another possibility is a coding philosophy (one which I follow to an extent) which says that you get out of a function as soon as it’s possible. Not necessarily for performance reasons, but it could make the code a bit more readable, and it reduces the amount of bugs. i.e. the IF is a safety check so they don’t have to do additional checks further down in the code.
If I’m debugging the application and I know the count is zero, I know that I don’t have to worry about any code after that IF. It could also be a good indicator that the problem is what called this function. Why is the count zero? If it should never be zero you can set a break-point on the return and then go up the call stack to find out WHY the count is zero.
The reverse could also be true. Maybe you’re not expecting the code below the IF to execute until another event happens. So you can set a break point AFTER the IF and find out what is calling this function at the wrong time.
I would get rid of the code, it adds complexity without increasing performance in your worst case scenario which is whats important when trying to hit a certain frame rate.
@Arcadenut: I follow the philosophy you stated, as well, but I’m aware that there is also the exact opposite philosophy that holds that every function should have one and only one exit point, in which case that “early out” would be incorrect. Seems like an insane way to do things, to me, but I know some professionals who assert that it is superior…so…make of it as you will.
Yeah, I’ve seen that. I think that is a horrible idea as it makes the code a lot harder to read in a lot of cases and it takes a lot more mental gymnastics to make sure it happens that way.