Adventure Game Studio

AGS Support => Advanced Technical Forum => Topic started by: abstauber on Sun 02/03/2014 14:16:51

Title: Is always assigning a value faster?
Post by: abstauber on Sun 02/03/2014 14:16:51
Hey,
I just wonder, how fast an "if" clause is.

Let's say I have a struct of 100 waypoints and I want to move those.

Code (ags) Select

struct wPoint{
    int x,y;
    bool active;
}
wPoint myWaypoints[100];


Now I could it like this
Code (ags) Select

    int i =0;
    while (i<100) {
      myWaypoints[i].x -=5;
      myWaypoints[i].y -=5;
      i++;
    }


or check first, if the waypoint needs to be moved in the first place:
Code (ags) Select

    int i =0;
    while (i<100) {
      if (myWaypoints[i].active) {
        myWaypoints[i].x -=5;
        myWaypoints[i].y -=5;
      }
      i++;
    }

So my question is: is plain variable assignment faster than doing a check first?
Title: Re: Is always assigning a value faster?
Post by: Wyz on Sun 02/03/2014 14:29:52
This depends on how many way points are active really. If there are only a few active checking would probably be faster: if most of them are active not checking would probably be faster.

You can actually sort of calculate this: give each operation a score: checking if a value is true: 1, Reading an index in a array: 1, reading a member value: 1, writing a member value: 1, adding two numbers 1.
The bigger the score the more time it would take to execute the less efficient the program would run.

In the first case you'd get (5 + 5 + 1) * 100  = 1100, in the second case you'd get something between 1 * 100 = 100 (all way points are deactivated) and (3 + 5 + 5 + 1) * 100 = 1400 (all way points are active) depending on how many would be turned on. You can now see that only when a large number of way points are active it becomes less effective to do the check. If 50% was active you'd get: (3 + 5 + 5 + 1) * 50 + 1 * 50 = 750 with the check which is more efficient then the 1100 without the check.
Obviously in reality the scoring would not be so well defined but this give an impression.
Title: Re: Is always assigning a value faster?
Post by: abstauber on Sun 02/03/2014 15:54:48
Interesting thought.
So checking a value and writing a value have both the score of 1? Is somehow thought, that checking costs more than writing. But that could be stoneage basic knowledge :D
Title: Re: Is always assigning a value faster?
Post by: DoorKnobHandle on Sun 02/03/2014 15:57:16
No that's the problem, Wyz used what's generally called a simplified cost model (that's why he gave every 'action' a cost of 1) - as he said, that's not realistic, it's just meant to give you a rough idea! :p
Title: Re: Is always assigning a value faster?
Post by: abstauber on Sun 02/03/2014 17:42:15
Yeah sorry - of course checking is a complex operation, whereas adding a value is just what it is. Thanks you two - I think got it now.
Title: Re: Is always assigning a value faster?
Post by: Monsieur OUXX on Mon 03/03/2014 10:45:51
In case it helps : http://www.adventuregamestudio.co.uk/forums/index.php?topic=33448.msg617692#msg617692

@abstauber : Additionally to what has been said earlier, In AGS, you must also consider the time required to access the memory cell of an array (the engine computes its position). In large arrays it can be slow, if I recall.
The only good solution in AGS performance-wise is to do the test yourself: do a function with "noloopcheck" and make it run on 100,000 entries. You'll see what's faster.

But as Wyz said: a big factor here is your algorithm's complexity: if many points are active, then testing the bool is more expensive. Otherwise, the other solution is more expensive.
Title: Re: Is always assigning a value faster?
Post by: Crimson Wizard on Thu 06/03/2014 17:34:42
Quote from: Monsieur OUXX on Mon 03/03/2014 10:45:51
@abstauber : Additionally to what has been said earlier, In AGS, you must also consider the time required to access the memory cell of an array (the engine computes its position). In large arrays it can be slow, if I recall.
Getting access for the 1st element is as fast as getting access for 1.000.000th, it just do (StartAddress + SizeOfElement * Index) and return the memory pointer.

In theory, having array so long that it is allocated over several "pages" in memory will make a sequence of random pick-outs from different parts of array slower. I say in theory, because in practice it mainly depends on how often and much do you do that.