System Timer32

[Bribe]

I think it's worthwhile because I am working on a projectile system that requires a lot of local variables and I don't want to have to declare them for every instance, rather base it off T32's mechanics but have direct access to the static method.

 

[emjlr3]

It just involves array look ups, variable setting, and a function call. Even for one instance, this is pretty fast. However, remember that that is not the only thing to consider. There is also the release() method (which is a lot faster than TimerUtils) and the create() method (which is also faster than creating a timer). Overall, for a standard timer utils kind of system, you would first have to use NewTimer() and then use SetTimerData(). On the loop, you would have to then use GetTimerData() per loop. In the end, you would also have to use ReleaseTimer(). Internally, those functions call other natives, while Timer32 simply sets variables and does array look-ups. So I'd say the difference would kick in even during the first instance.

first off, no one really cares about create or release - the real bread winner is the periodic lookup, which in a realistic sense is all we really need to compare (no need to get into the nuts and bolts of that)

IMO, one

GetHandleId()-offset

should be faster then one loop through with an array lookup, so I cant see one instance of one spell being any faster periodically - obviously through 10 more on top of that and you have yourself a winner, considering the additional native calls and arithmetic, along with timer events

However, that is when comparing to TimerUtils. When comparing it to a standard struct stack, it also has a better means of setting and retrieving data. (there are no arithmetic operations)

simple addition cannot be very taxing, and I doubt the difference is significant compared to an array lookup, I would however like to see some numbers for that comparison

1 per loop of the timer, not 1 per instance

take a look at my example script - I had only one in there - I was aware of that coming into this discussion

All of that is good, but the bolded part is the key. All the "struct stack loops" are added to once trigger, which gets evaluated, which is the lowest overhead you can have on a function call, off memory. One timer per loop makes overhead of the timer expiring + function call, with T32 there is only one timer firing and the function calls all come from one trigger evaluate, in other words machine code loops through the loops and calls them each instead of jass code (inside the TriggerEvaluate).

I don't get this

you mean, in the instance of one spell (obviously many many spells all at once will overtax a system using a struct stack/spell), the overhead of:

//timer expires
local integer i=1
local data d
loop
  exitwhen i>N
  set d=D<i>
  set i=i+1
endloop</i>

is greater then

//trigger timer expires
call EvaluateTrigger(Trigger)
local thistype this=thistype(0).next
            loop
                exitwhen this==0
                call this.periodic()
                set this=this.next
            endloop
            return false

?? I fail to see how (though i didn't get your last response)

now, having said all that, in the grand scheme of things - this doesn't really matter at all, considering that 99.9% of the power required for spells isn't related to data lookup at all - so really all of this is probably, and ultimately, superfluous, IMO

 

[Nestharus]

I wouldn't say that it was superfluous at all. See the stress tests on this page to see where T32 fits into the picture -> http://www.thehelper.net/forums/showthread.php/161340-TimerQueue


Also, to understand just how quick evaluating one trigger over many can be

Frames per Second Benchmark Tests (32x per second)

Light Event by nestharus
    x1500: 2-3 (avg 3)
    x1200: 15-22 (avg 15)
Heavy Event by nestharus using Light features
    x1500: 2 (avg 2)
    x1200: 14-16 (avg 15)
Heavy Event by nestharus using Dynamic Features (like jesus4lyf's event)
    x1000: 8-10 (avg 10)
    x1200: 0-3 (avg 1)
Event by jesus4lyf
    x1000: 5-6 (avg 5)
    x1200: 0-1 (avg 1)

Also, if you notice, short variable names also make a huge difference. The only difference between this test
Heavy Event by nestharus using Dynamic Features (like jesus4lyf's event)

and this test
Event by jesus4lyf

are the variable names ;P

 

[emjlr3]

realistic test scenario please

 

[Infinitegde]

Question: Could you possibly make it so that the engine calls a static function per tick, that way instead of having to do certain tasks every instance every tick we can do it just once per tick. (For example, I need to get the x and y location of a specific unit and dont want to call GetUnitX&Y in every .periodic())

 

[Bribe]

Question: Could you possibly make it so that the engine calls a static function per tick, that way instead of having to do certain tasks every instance every tick we can do it just once per tick. (For example, I need to get the x and y location of a specific unit and dont want to call GetUnitX&Y in every .periodic())

Basically what I said - add a second module which allows direct access to the static method, allowing us to have more control of what's happening.

 

[Laiev]

static method callback takes nothing returns nothing
    //~~~~~
endmethod

method periodic takes nothing returns nothing
    call thistype.callback()
endmethod

implement T32x

like this?

 

[Bribe]

No, that's a nonsense method. Allocating two integer arrays just to waste them.

I mean like this:

static method periodic takes nothing returns boolean
    // Actions...
    return false
endmethod
    
implement StructTimer

 

[Nestharus]

Note that due to the way this is ordered, the stop/start method calls from the loop will end up evaluating triggers.

Furthermore, the module is written semi poorly. It would be better to have a next/prev that is global to all modules to save on spamming the global scope. If there are 8000 timers running 32x a second, then the map is already going to be unplayable.

Also, keep in mind that the cost of a method call can be very expensive if there are many locals declared within that method call. It'd be smarter to split the module into 3 modules to save on the method call.


Also, in the exitwhen statement, 0==this is faster than this==0. I'm sure I mentioned that before.


Next, if there are 0 instances left for a struct, that struct's trigger condition should be removed from the evaluated trigger. If there all structs have 0 instances, I want to say the timer should be paused, but the fact is that pausing a timer can cause serious bugs with TimerStart.

If the removed instance is part of the current evaluating trigger condition, would need to go into a stack for after the trigger evaluation. If not, the trigger condition can be removed directly.


Also, you should really support being able to remove the current expiring instance and adding a new instance.

 

[Bribe]

Rather than adding/removing conditions, what would be the comparable overhead of [ljass]TriggerRegisterTimerExpireEvent[/ljass]? That way you could just enable/disable the module's trigger when it's empty.

 

[Nestharus]

Overhead on TriggerRegisterTimerExpireEvent is pretty bad.. remember that you have the whole if (TriggerEvaluate) then Execute structure and who knows what else.

 

[Dirac]

I modified the T32x module in my map to this, it's actually faster

        private static method onInit takes nothing returns nothing
            if null==List then
                set List=Filter(function thistype.PeriodicLoop)
            else
                set List=Or(List,Filter(function thistype.PeriodicLoop))
            endif
        endmethod
    endmodule

    private function OnInit takes nothing returns nothing
        call TriggerAddCondition(Trig,List)
        call TimerStart(CreateTimer(),PERIOD,true,function OnExpire)
    endfunction

@Bribe Why would you like to have more than 1 static method period on your struct? i mean it's possible, but why?

 

[Bribe]

It wasn't that I didn't want to have more than 1 periodic, it was that I wanted to have the callback only called once per timeout instead of once per instance, and allow me to have access to all members.

Well CTL32 by Nestharus fixes those problems albeit with a hideous API.

 

[Jesus4Lyf]

Nestharus fixes those problems albeit with a hideous API.

xD lol