Timer Tools vs Timer Utils nowdays

[WereElf]

I've seen in several posts that Timer Tools is much better/faster than Timer Utils. Is that still true, or Timer Utils has been improved enough to keep up with Timer Tools?
Wietlol keeps suggesting people to use Timer Utils, so I'm wondering if it's the better choice nowdays.

And one more thing:
For PERSONAL use ONLY, can I use my own system?

library TimerActions
    globals
        private integer count = 0
        private timer array timers
        private timer array timers2
        private timer array timers3
    endglobals

    function RecTimer takes timer t returns nothing
        if count <= 8190 then
            set timers[count] = t
            set count = count + 1
        elseif count <= 16380 then
            set timers2[count - 8191] = t
            set count = count + 1
        elseif count <= 24570 then
            set timers3[count - 16381] = t
            set count = count + 1
        else
            call DestroyTimer(t)
        endif
    endfunction

    function GetFreeTimer takes nothing returns timer
        if count > 16380 then
            set count = count - 1
            return timers3[count]
        elseif count > 8190 then
            set count = count - 1
            return timers2[count]
        elseif count > 0 then
            set count = count - 1
            return timers[count]
        else
            return CreateTimer()
        endif
    endfunction

    function RecPeriodicTimer takes timer t returns nothing
        call PauseTimer(t)
        call RecTimer(t)
    endfunction

    function ClearTimer takes timer t, boolean b returns nothing
        call FlushChildHashtable(udg_Table, GetHandleId(t))
        if b then
            call PauseTimer(t)
        endif
        call RecTimer(t)
    endfunction
endlibrary

If I'm not saving the same timer more than once, this should work just fine.
Wouldn't that be the fastest way to recycle timers?

 

[BPower]

In which scenario do you need a stack with more than 8910 recycled timers?

TimerTools and TimerUtils are totally different types of timer systems.
For starters go with TimerUtils, otherwise go with TimerUtils.

TimerTools is in theory much much faster than any other timer resource,
IF you run multiple timers during the same time. You may measure a
difference in ms at 50+ timers. The difference becomes significant
at 1000+ timers.

TimerTools is not perfectly working ( statement of the author ).

 

[Bribe]

In most cases, a single timer looping through a stack is more convenient. Speed isn't a percievable issue, and it becomes faster than TimerUtils if you're running all instances on a fast period anyway.

Spell System uses one timer and loops through all indices to see if their timeouts are ready. The result is that one timer is used for all spells in the map.

 

[Nestharus]

Timer Tools breaks native timers.. I have no idea why, lol. They'll expire prematurely. You don't even have to be running anything. Cnping it into the map is enough to break them.

In most cases, a single timer looping through a stack is more convenient.

Timer Tools takes this idea and expands it out to several timers via a timer queue. It uses a queue instead of a stack. When a timer expires, the top of the queue is popped, iterated over, and then added to the back (more or less). From here, it has one timer queue per timeout. It also uses some cool maths to muddy up the timeouts so that timeouts that are close enough will merge together into the same timer queues. If the timeout is small enough, it drops the queue in favor of a single timer (like a .03125 timeout going on to a single timer instead of several consecutive timers). Uhm, I probably didn't mention this, but multiple functions reside on a single timer queue node, much like T32/CTL. T32/CTL are examples of a timer system with only 1 node. If you were to have a large timeout and a string of timers, all with the same timeout, popping/pushing nodes from/to the queue, you'd then have a portion of Timer Tools. If you expand that out to multiple timeouts, each with their own queues, and also add in some maths, you now have Timer Tools.


The thing's pretty smart and well designed. If only it worked : (. I mean it can definitely work. Somebody just needs to debug it. I frankly don't have time, haha. What I can do is release design diagrams for each of my resources so that they are easy to understand. These systems can then be re-engineered, following those designs, and properly debugged. The original source can also be used to expedite the process.


One new feature of Timer Tools could be to use TriggerExecuteCount tp retrieve the id of the timer instead of GetHandleId. You'd then register triggers to the timers. If you use the Trigger resource, you can then easily remove code without a garbage collector too. The only problem is that the trigger would have to be executed N times, making creation horrid. Recycling helps >.>. You'd have to do some sort of initialization timer that you'd pass timers to. The time spent in this timer would reduce the time until the next expiration. This initialization timer would just call TriggerExecute to initialize new triggers without destroying the map. We'd have to compare GetTriggerExecCount to GetHandleId to justify the cost of this feature. KT2 did this, but it just spammed TriggerExecute when you did the creation. Your map would completely die if you tried to create a large amount of timers.