It is (or should be) common knowledge that the current implementation of for-loops of the editor is pretty... ineffective, especially for loops with many actions and/or nested loops.
The original for-loops have this in their custom script:
As you see, the subfunctions get implemented twice! If you nest 3 for loops that would mean that the most inner loop actions actually have 8 copies of themself in the map code. The reason why they made this is to make this foolproof... but that results in too much code for simple for loops like:
ForEachInteger(int,1,10,1) ...
To get simple efficient for loops which simply count up you can do the following:
Create a new action named something like "ForEachIntegerUp", click on Options and check "loop" and "subfunctions".
Copy the parameters of the ForEachInteger function.
Create an actions subfunctions and name it "actions" .
Copy the following in the custom script section:
With efficiency I don't mean the execution speed but the amount of code created. Since we are pretty restricted ( I think it was around 2MB) on code and variable memory this will be important for big projects. Reference thread
Of course you are right: when you only use one function inside the loop and this function contains XY subfunctions, then we won't have that much code generated like when all subfunctions were directly in the forloop.
Also this was to show what can be done with custom actions, because I think not too many people know about this yet. It will be pretty easy to create kind of a for (x,y,) loop with this, and this is the loop I used the most up to now, in my map.
I've started using 'pick integer' over 'for' loops, and if I need to use nested loops for something, I use one of each. I'm curious, anyone happens to know how efficient the code is on that?
Pick Integer is very fast. A while loop is still a bit faster (because it doesn't use as many function calls), but Pick Integer is already pretty damn fast.
while ((var <= ae && ai>=0) || (var>=ae && ai<=0)){}
So basically Continue while:
Start Value is smaller or equal to End Value AND Increment greater or equal to 0 OR
Start Value is greater than or equal to End Value AND Increment smaller or equal to 0
Sure, it adds comparisions, but integer comparisions are damn quick. Good performance and the script size will stay small.
It is (or should be) common knowledge that the current implementation of for-loops of the editor is pretty... ineffective, especially for loops with many actions and/or nested loops.
The original for-loops have this in their custom script:
As you see, the subfunctions get implemented twice! If you nest 3 for loops that would mean that the most inner loop actions actually have 8 copies of themself in the map code. The reason why they made this is to make this foolproof... but that results in too much code for simple for loops like: ForEachInteger(int,1,10,1) ... To get simple efficient for loops which simply count up you can do the following:
Create a new action named something like "ForEachIntegerUp", click on Options and check "loop" and "subfunctions". Copy the parameters of the ForEachInteger function. Create an actions subfunctions and name it "actions" . Copy the following in the custom script section:
42 Posts!! (sorry 'bout that :) )
@Rushhour: Go
If you kick off threaded functions / actions from a for loop its not really that inneffective.....
Its in there twice for two reasons.... In one your decrementing so i- and another for incrementing i+
when actually running the code it would only have 1 additional if for it to check rendering any improvements in speed unnoticable.
Only case this would matter is if youve managed to max out your alloted script memory, Which I dbout anybody intelligent has managed to do.
With efficiency I don't mean the execution speed but the amount of code created. Since we are pretty restricted ( I think it was around 2MB) on code and variable memory this will be important for big projects. Reference thread
Of course you are right: when you only use one function inside the loop and this function contains XY subfunctions, then we won't have that much code generated like when all subfunctions were directly in the forloop. Also this was to show what can be done with custom actions, because I think not too many people know about this yet. It will be pretty easy to create kind of a for (x,y,) loop with this, and this is the loop I used the most up to now, in my map.
its easy to fix: use while loops.
noticed this problem too, since then i only use pick each integer or while, never for each int.
I've started using 'pick integer' over 'for' loops, and if I need to use nested loops for something, I use one of each. I'm curious, anyone happens to know how efficient the code is on that?
@ChromiumBoy: Go
Pick Integer is very fast. A while loop is still a bit faster (because it doesn't use as many function calls), but Pick Integer is already pretty damn fast.
Can't do it simply like this?
while ((var <= ae && ai>=0) || (var>=ae && ai<=0)){}
So basically Continue while:
Start Value is smaller or equal to End Value AND Increment greater or equal to 0 OR
Start Value is greater than or equal to End Value AND Increment smaller or equal to 0
Sure, it adds comparisions, but integer comparisions are damn quick. Good performance and the script size will stay small.
Yep, you're right about that. Can you explain to me why the blizzard developer(s) implemented it so stupidly then? :-O
The only "advantage" would be that the ai > 0 / ai <0 is only checked once ... but that can't be the reason ;P