Splitting hairs again

Hey,

I am sure I am just splitting another hair here, but is there a significant computational difference between looking at a class's public member vs calling one of its functions?

Basicly every class in my game has a

Code:

public:
   bool Active;
   void Draw(SpriteBatch SB);

Then in the game I have a function Draw() where I have two options for checking to see if I should drawn an object... I wasn't sure if they were computationally equivalent so I figured I'd ask.

first option

Code:

void Draw()
{   
  if(ThisObject.Active)
    ThisObject.Draw(spriteBatch);
}

This turns into ALOT of iffs in my draw code and I was starting to get annoyed by it.
Second option is to put the check within the Object.Draw(SB) fuction and then in the game Draw() code only call.

Code:

void Draw()
{
  ThisObject.Draw(spriteBatch);
  ThatObject.Draw(spriteBatch);
  // ect
}

So basicly which is taking more process power?
ThisObject.Active || ThisObject.Draw#SB)

They'll be largely equivalent: small differences at most.

The only potential difference will be in passing spriteBatch. If that is an expensive operation (eg copying a huge object) then your first option has the advantage of eliminating that expensive operation - if thisObject.Active is false. If spriteBatch is just a small value (eg an int) or is being passed by reference, that difference is largely negligible.

Note: if you are calling ThisObject.Draw() many times in succession (eg in a loop that does it 1000 times) there might be a small advantage of providing a ThisObject.MultiDraw(), since that can eliminate multiple redundant checking of ThisObject.Active.


In general, however, if performance really matters, you would be better off using a profiler to find hotspots. Those "small differences" I referred to can become significant in some cases (eg the code you showed is innermost in a very tight, performance critical, loop). It is best to use a profiler to find such cases, rather than optimising on a hunch. Short of that, however, go for whatever makes your job as a programmer easier (eg avoiding code duplication).

If you really want to optimize then more information are needed. If for example you have 100k objects and you know that 10% are only active then maybe you want to keep the active objects in a vector. So when an object activates you add to the vector and when deactivates you remove. Then you can Draw only the objects that are in the vector.
If you activate/deactivate a lot more than you Draw() maybe you don't want the above. But then again you won't only have "this and that" object so you would end up with a vector that holds all objects. In that case maybe you load a pair to the vector loading the activation status and the reference to the object so you don't need to reference the object to get the active status which now since we are talking about a 100k vector it might not be good due to cache misses.

If you only have a handful or objects and you are debating between 1st and 2nd then the 2nd approach seems better and maybe a slightly faster (though I doubt anything noticeable). If this is early in the program and you might end up with a vector of objects as said above then don't put the check in Draw() yet, but wait until you move further on the design. In other words avoid premature optimization. Once you are settle you can see what is the best approach.

EDIT: grumpy is right about the object being passed making a difference, so indeed the two approaches can have a difference so my statement is not good

It is best to use a profiler to find such cases, rather than optimising on a hunch. Short of that, however, go for whatever makes your job as a programmer easier (eg avoiding code duplication).

Yea I plan to install a profiler on my machine when I get to the optimization phase of the project. I am still just plowing through as much code as I can to hit my self imposed deadline. After I have the entire engine with all functions writen in the original design then I plan to go into the phase of profiling everything. I think if I get caught up on that now I'll spend too much time disecting code when I should be finishing the project lol.

I do like to make intelligent decisions when they present themselves and thats why I needed to know if there was a significant difference... Now I have to look and see how computationally expensive a SpriteBatch is to pass. Thanks for pointing that out, though I should have thought about the function making a copy everytime its called, it somehow slipped my mind.

Thanks Grumpy as always for the good information.

In other words avoid premature optimization. Once you are settle you can see what is the best approach.

For that I can agree but I'm already 2500 lines of code in and if I don't make intelligent design systems as I go then bugs get really hard to track, thats why I wanted the second option as it has all successive draw calls at the same tab point in a nice formatted column. I expect the finished product will be probably 3-5x this size.

If spriteBatch is just a small value (eg an int) or is being passed by reference, that difference is largely negligible.

It turned out to be a class that stores the values needed to render sprites and then renders them to the screen. So passing by reference would probably be better than creating a new one for every object drawn. Otherwise the point of the class would seem negatated by using it the way I was. Though it doesn't seem incredibly large, I would say it is significantly larger than an int.

Considering I was doing this for every object drawn in the game that may be why I saw a significant slowdown when I allowed the player to shoot bullets with only a slight delay (ending up with a few hundred to a maximum of 1000 on screen).

Originally Posted by Lesshardtofind

For that I can agree but I'm already 2500 lines of code in and if I don't make intelligent design systems as I go then bugs get really hard to track, thats why I wanted the second option as it has all successive draw calls at the same tab point in a nice formatted column. I expect the finished product will be probably 3-5x this size.

There is nothing wrong with discarding existing code, and implementing new code based on the lessons you learned (and mistakes you realised you made) when doing it the first time. But it does require willingness to let go of the existing investment of effort.

There is nothing wrong with discarding existing code, and implementing new code based on the lessons you learned (and mistakes you realised you made) when doing it the first time.

Yea I do try to improve code over the life of a project often. I usually set a list of things I want added this week. I write a bunch of psuedo code and design modules to see what is the most logical and least likely to create bugs. Then I code it all based off those original instincts. After I finish my list I go back and alter code. Ie adding comments or improving flow and simplifying logic (this one happens a lot). After that I test all the features in the game when I am satisfied the weeks work is bug free I move on.

As I am still a beginner programmer compared to many here I like to drift by with questions that I can't answer. Some of those questions such as that "concepts of memory" post lead to a lot more understanding than I expected lol. This site has been continually helpful in giving me bumps in the right direction.

Your point about passing by ref made me look back at my entire game class flow and I realized I was passing copies of my Content Manager, Graphics Devices and SpriteBatches when it could all be done by ref. That should cut out some stack memory usage.