Code Optimization

If you''re going to be doing lots of modifications on members of masterClass->playerManager->player[currentPlayer] at the same time, then do this:
CWhatever *player=&masterClass->playerManager->player[currentPlayer];
player->health=100;
player->blah=1000;
etc.

Where CWhatever is the data type of masterClass->playerManager->player[currentPlayer]

This is just an extended explanation of what SeanHowe suggested.
One reason that this function could be slow is a cache miss.
When you read from an area of RAM that you have read from (or written to) recently the processor will read it from the internal cache which is very fast (often only one cycle). Cache operates by keeping a copy of the memory around the accessed address in a very fast memory so that subsequent reads/writes to the given address and the nearby addresses are very efficient.

If you haven''t used the location for a while then the processor will probably have to get the data from the main RAM, which is much slower.
In your code:
masterClass->playerManager->player[currentPlayer]->health

you do 3 or 4 memory accesses (read playerManager, possibly read currentPlayer, read player[currentPlayer], write health). Since these probably were allocated in different areas of memory accessing any of these values does not help accessing any others.

In the view of all this you should arrange your accesses so that things that you use at around the same time are kept together and vice versa - try to group accesses to the same structure.
So if you adjust your health right after, say, you adjust your fuel the penalty will be much lower. And do the trick SeanHowe suggests, that will save some cycles too. it will also free some precious cache since once the address of player is known, the addresses of playerManager etc are not needed and can be used to caches something else.

Or just use ASM

U see all that vc++ class stuff is for very slow programs that u wanna create fast and with little problems ... so they say... but i bet as u see u have a lots of problems when it comes to speed....and games is about speed .. is it not?

Anyway i always get a headache when i look at how u guys access a matrix of properties using classes ... ...oh my God they say ASM i complicated...hmmm come here and see a VC++ CLASS in action

No kidding now...

Whatever language u like u will always have to go back to ASM... at least partial... if u wanna have more speed then ever.

Bogdan

Ok, I''ve got a question. I am almost exclusively a c++ programmer, BUT I remember when I first learned C, that things like this:


myStruct.internalMember.nextMemeber.etc.x = 50;


would get compiled into a piece of code EXACLTY as efficient as this


myStruct.x = 50;


because all of the values (offsets) are known at compile time, and therefore it is a simple optimization for the compiler to turn all of those offsets into one total offset.

NOW .. obviosly if each of those dereferences were C++ member function calls ... then it''s going to be bad (but what about if they are all inline?). and if they are virtual functions, it is guaranteed not to be optimizable. But if masterclass is basically a struct ... since he''s access the member playerManager directly, and it is a struct, cause he''s accessing player directly ... then shouldn''t there be some way to rearchitect these data structures such that unneccesary flexibility is removed (any member that need not be a poiner, could possibly become an actual (non-pointer) data member) .. this may not work, if he is using features of the pointer situation (dynamic substitution .. etc) but if all he is doing is holding players ... then perhaps he can lay it out so the line becomes:


masterClass.playerManager.players[currentPlayer].health = 100;


which should allow the compiler to optimize away at ONE of the pointer indirections (masterClass.playerManager.players is just a constant offset) ... so that would be a 25% improvement in efficiency ...

It would have been nicer ... but the array part [currentPlayer] cannot be optimized away, because it operates dynamically, and therefor the offset before it ... itself ... and the offset after it (.health) each will have to generate code. If you see a way to change the situation such that all of the static offsets are all in a row (either all before or all after) and then all the dynamic offsets are grouped .. you should see a 50% or so performance improvement. Good luck.

Sorry for not responding earlier, I have just been so very busy lately with my school work and football practices. I have had time for nothing. Anyways, thanks for your help, I learned a little... but I''m still a bit confused with this. I know that I have to totally rework my design, but I''m not sure how to eliminate the memory accesses. I have been informed that maybe I should let a function inside the class modify data within itself. Is this right or what? I''m just not sure. Oh and by the way, in my code, I use, more specifically:

masterClass.playerManager.player[currentPlayer].health = 100;

not

masterClass->playerManager->player[currentPlayer]->health = 100;


Thanks for your time.