Operation limit

[Zwiebelchen]

Well, I had some trouble the last weeks with the operation limit.

Though I solved the problems, I was wondering if someone could give me proper information about the operation limit itself:


1) How many operations are (on average) required to reach the operation limit?

2) What possible ways are there to create a new threat and thus resetting the operation limit? I know that you can use zero-timers, but are there other more elegant ways?

3) Is there a way to detect wether you are close to the op limit?

That's all for now. Thanks in advance.

 

[Azlier]

2. The best way to avoid the op limit is by started a new thread via TriggerEvaluate or TriggerExecute.

 

[weaaddar]

1.The op limit is hard to calculate and not every action consumes equal amounts of it.
2. TriggerEvaluate, TriggerExecute or TriggerSleepAction. If you have a big loop you probably want to just add a sleep after some number of iterations.
3. No way to detect.
Actually here is my quick test suite.

//! zinc
library test requires Table
{
    integer C0 = 0;
    integer C1 = 0;
    integer C2 = 0;
    integer C3 = 0;
    integer C4 = 0;
    integer C[];
    integer C10 = 0;
    integer C12 = 0;
    Table table;
    function test0()
    {
        while(true)
        {
            C0 +=1;
        }
    }
    
    function test1()
    {
        C1+=1;
        test1();
    }
    
    function test2(integer x)
    {
        C2+=1;
        test2(x);
    }
    function test3()->integer
    {
        C3+=1;
        return test3();
    }
    
    function test4(integer x)->integer
    {
        C4+=1;
        return test4(x);
    }
    
    function test5()
    {
        while(true)
        {
            C[0] +=1;
        }
    }
    
    function test6()
    {
        C[1]+=1;
        test6();
    }
    
    function test7(integer x)
    {
        C[2]+=1;
        test7(x);
    }
    function test8()->integer
    {
        C[3]+=1;
        return test8();
    }
    
    function test9(integer x)->integer
    {
        C[4]+=1;
        return test9(x);
    }
    
    function test10()
    {
        C10+=1;
        test10();
    }
    function test11()
    {
        table[0] +=1;
        test11();
    }
    
    function test12(integer x,integer y)
    {
        C12+=1;
        test12(x,y);
    }
    
    function onInit()
    {
        timer t = CreateTimer();
        timer t2 = CreateTimer();
        table = table.create();
        TimerStart(t,1,false,function()
        {
            BJDebugMsg("Globals");
            BJDebugMsg(I2S(C0));
            BJDebugMsg(I2S(C1));
            BJDebugMsg(I2S(C2));
            BJDebugMsg(I2S(C3));
            BJDebugMsg(I2S(C4));
            BJDebugMsg("arrays");
            BJDebugMsg(I2S(C[0]));
            BJDebugMsg(I2S(C[1]));
            BJDebugMsg(I2S(C[2]));
            BJDebugMsg(I2S(C[3]));
            BJDebugMsg(I2S(C[4]));
            BJDebugMsg("test10 "+I2S(C10));
            BJDebugMsg("test11 "+I2S(table[0]));
            BJDebugMsg("test12 "+I2S(C12));
        });
        test0.execute();
        test1.execute();
        test2.execute(0);
        test3.execute();
        test4.execute(0);
        test5.execute();
        test6.execute();
        test7.execute(0);
        test8.execute();
        test9.execute(0);
        TimerStart(t2,0,false,function test10);
        test11.execute();
        test12.execute(0,0);
    }
}

//! endzinc

Here are some quick thoughts:
1. Timer and trigger threads have the same number of ops.
2. Recursion gets more bang for your buck vs loop when you don't have parameters.

3. Array members consume much more op limit then non-array members. Hashtable consume even more.
4. Functions without parameters seem to preform the best, regardless of if they have a return.
5. The return statement seems to make no effect on op limit. This may because it never returns and thus never has to populate the stack.

Anyway the number is something like 33,333 global var reads in a loop or 45,000 global var reads in a recursive loop. Array reads are more get about 10,000 less on average. Inf recursion with a hashtable yielded a pathetic 15,000.

In theory if you want to be nuts you can just have a function that has 100,000 statements in it of all just a variable incrementing itself. It should crash and then one could figure out how many raw statements you can process in one function by using a similar approach. I think Cjass might be able to this.

The op limit can be kind of low, but as long as you don't try something crazy you should be safe.

 

[Zwiebelchen]

Thanks for the detailed informations.
And yes, of course, the operation limit should - at least most of the time - not be a problem, but you can reach the op limit very fast with Map-Init functions, especially enumerations.

For example, in my rpg, I attach like 20-30 custom stats to all placed neutral hostile units on the map on map init, by just using global arrays with an indexing system. I was wondering why some mobs didn't have the custom stats, until I found out, that I exceeded op limit on map init.

I don't really understand why there is an operation limit to functions called on map init, as those functions are called during the map loading process anyways and thus can not create a "freeze", but well, that's blizzard logic.

 

[Jesus4Lyf]

I don't really understand why there is an operation limit to functions called on map init, as those functions are called during the map loading process anyways and thus can not create a "freeze", but well, that's blizzard logic.

Try doing [LJASS]call TriggerExecute(GetTriggeringTrigger())[/LJASS] on map init and say that again. :thup:
You can freeze the map with object editor data even - an orb effect which fires itself (causes infinite loop on load). XD