Allright then; the following is valid for WC3, not yet tested if SC2 uses a similiar system!
The number of executions of a loop can be calculated with following formula: n(x)= (300,000 / (2x+1) ) with n being the number of executions and x being what I call "ops".
That would mean that an empty loop in an own thread will be executed 300,000 times until it breaks down. This can't be proved since inputting a counting variable will influence the result.
That's the basic setting. This would return a value of 42857. Seems pretty random, but it follows some logic. When looking at the formula this would be the rounded outcome for x=3.
I did various tests and discovered following things:
set TestI=TestI+1 increases x (the "ops") by 3. one for referencing the variable TestI, one for using an calculation operator (+) and one for referencing the number 1.
When I try the following:
set TestI=TestI+1
set someInt=someInt+8436
I get 23077 as a result. Again, this is the rounded outcome for x=6, again the same explanation: Two variable or number references and the +.
When using:
set TestI=TestI+1
set someInt=someInt
set someInt=someInt
set otherInt=otherInt
I get the same result as above, again 6 ops referenced!
Ok thats the basics.
When you want to know how many times your loop will get executed you need to simply count all these things, but there are more things to keep in mind:
A native function reference itself adds 0,5. If it has a parameter and you use some variable or value you will need to add 1 for this. If you do some math like "var + 5" in the parameter, you will need to add 3.
If you use an own function you will need to add 1 for the function itself. Same like for natives is valid for the parameters, but: You will need to count the stuff done inside the function as if it was in the loop.
A completly empty if-then-else would add 0,5 (but noone ever has this), so you need to add 1,5 for an if-then-else which has something in it. And: Only the code reached by the loop will count! If the outcome is random then you would need to guess or add the highest possibility to your x.
If there is a loop inside your loop, you will need to count all stuff that is done inside of your nested loop like you did before and then multiply it with the number of executions for the inner loop.
So having a lot of if - then -elses, inner loops that have different number of executions makes it really hard to get the actual number of maximum executions of your loop.
But as a general note you could remember that instead of calculationg myVar+CONST 4 times, it would be better to save it in another variable. Or it would be better to use natives instead of own functions.
I did this for a PathExists function which then worked pretty fast but which still needs some Waits after XY executions to make sure it doesn't suddenly stop. ;)
Let's see if I explained clearly :D, how often will the following code be executed?
Do you know that there exists point functions that should (at least when reading their names, haven't used them yet) return things you may need.
I'm not sure about the function name right now, but this one function returns the "pathingcost" (?) between two points. So have a try if this is the distance between the two points or some value which can be used as the distance. It's the same problem like we had in WC3 scripting, after several iterations you simply exceed the operation limit and you would need to use a wait.
I did some testing on the operation limit in WC3 and found a formula where you could simply calculate how often a loop will be executed in its own thread until the game breaks it down. As a basic you can say that more function calls, variable references and operations (like +-*/ && ||) drastically decrease the limit. Will post more details later if someone wants to know this. :D
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Allright then; the following is valid for WC3, not yet tested if SC2 uses a similiar system!
The number of executions of a loop can be calculated with following formula: n(x)= (300,000 / (2x+1) ) with n being the number of executions and x being what I call "ops". That would mean that an empty loop in an own thread will be executed 300,000 times until it breaks down. This can't be proved since inputting a counting variable will influence the result.
My testing function looked like this:
That's the basic setting. This would return a value of 42857. Seems pretty random, but it follows some logic. When looking at the formula this would be the rounded outcome for x=3. I did various tests and discovered following things: set TestI=TestI+1 increases x (the "ops") by 3. one for referencing the variable TestI, one for using an calculation operator (+) and one for referencing the number 1.
When I try the following: set TestI=TestI+1 set someInt=someInt+8436 I get 23077 as a result. Again, this is the rounded outcome for x=6, again the same explanation: Two variable or number references and the +.
When using: set TestI=TestI+1 set someInt=someInt set someInt=someInt set otherInt=otherInt I get the same result as above, again 6 ops referenced!
Ok thats the basics. When you want to know how many times your loop will get executed you need to simply count all these things, but there are more things to keep in mind: A native function reference itself adds 0,5. If it has a parameter and you use some variable or value you will need to add 1 for this. If you do some math like "var + 5" in the parameter, you will need to add 3. If you use an own function you will need to add 1 for the function itself. Same like for natives is valid for the parameters, but: You will need to count the stuff done inside the function as if it was in the loop. A completly empty if-then-else would add 0,5 (but noone ever has this), so you need to add 1,5 for an if-then-else which has something in it. And: Only the code reached by the loop will count! If the outcome is random then you would need to guess or add the highest possibility to your x. If there is a loop inside your loop, you will need to count all stuff that is done inside of your nested loop like you did before and then multiply it with the number of executions for the inner loop.
So having a lot of if - then -elses, inner loops that have different number of executions makes it really hard to get the actual number of maximum executions of your loop. But as a general note you could remember that instead of calculationg myVar+CONST 4 times, it would be better to save it in another variable. Or it would be better to use natives instead of own functions.
I did this for a PathExists function which then worked pretty fast but which still needs some Waits after XY executions to make sure it doesn't suddenly stop. ;)
Let's see if I explained clearly :D, how often will the following code be executed?
Do you know that there exists point functions that should (at least when reading their names, haven't used them yet) return things you may need.
I'm not sure about the function name right now, but this one function returns the "pathingcost" (?) between two points. So have a try if this is the distance between the two points or some value which can be used as the distance. It's the same problem like we had in WC3 scripting, after several iterations you simply exceed the operation limit and you would need to use a wait.
I did some testing on the operation limit in WC3 and found a formula where you could simply calculate how often a loop will be executed in its own thread until the game breaks it down. As a basic you can say that more function calls, variable references and operations (like +-*/ && ||) drastically decrease the limit. Will post more details later if someone wants to know this. :D