Key Timers Attachment System - The best?

[Captain Griffen]

Due to a neat little And( ) boolexpr creation usage, assuming that they are programmed properly in terms of performance (not at all clear), then in normal use it should be faster than RT slightly, making it over 20% faster than TT, and considerably faster than TU (exact benchmarking between them is impossible).

Note that this applies when using only one timeout. When using multiple time outs it'll be slightly slower for each extra one by the summation of (cost of timer expiring / discrete timeout value).

[Vexorian]

Originally Posted by Tyrande_ma3x

Didn't feel like creating a new thread, sorry for reviving this.
Since he updated the system, he says that it is now the fastest timer system in existence, being ~22% over the speed of Timer Utils Red. I have no idea how it is possible, can someone benchmark and confirm it? It seems like he doesn't want to show his test triggers.

It's very easy to come up with some thing faster than another thing if it is not necessary that the new system actually works and provides the same functionality than the other thing... Key Timers are still broken in the sense they don't work. Though I guess the world is crazy enough that people would prefer speed over actual functionality... But really, if you want speed and something as non-flexible as this, then you can already do the typical struct loop method, this time with a bigger time out, that is equivalent to this thing, much faster because there is no overhead, simpler code, and it is as broken as key timers, but will use much less code...

The benchmarking is not believable as both things work radically different, comparisons in percentage don't make a lot of sense.

Due to a neat little And( ) boolexpr creation usage

He could just have used two Trigger Conditions, sounds silly of an improvement anyway, if this really improves speed by that big of a percentage it means what people have feared to accept since ages ago - That timer systems were fast enough already.

[emjlr3]

its no less accurate than a loop - and far easier to use (generalizing this from usage of TT, not actual KT use)

[Vexorian]

it's as inaccurate as a loop, just slower, if the point for using something inaccurate is speed, then go with the fastest one...

[cohadar]

Originally Posted by Vexorian

For example, what if blizz releases a SetHandleUserData native?

I presume nothing would change. Implementations are irrelevant anyways.

[Vexorian]

... that was mostly the point.

[emjlr3]

Difference being that eventually, a system like TT, would become faster then a loop, after you have a few timers firing simultaneously (or so Cohadar claims)

Where TT shines (and I use this term loosely), is that all inaccuracy is the same, as such, the system is very precise; a loop suffers from both inaccuracy and lack of precision (not that it really matters at the timer intervals that require max efficiency)

Easy isn't easy when it sacrifices flexibility and functionality that has to be made up elsewhere. That's retard logic.

I fail to see your logic

TT_Start and TT_GetData are far easier for me to use, especially when I have multiple structs for the same spell that I would have otherwise needed to loop through seperately, using an array and index for each (not to mention updating the stack, etc.) - I assume KT works similarly

there is no loss of functionality - and if by flexibility you mean timer speed, well, .04 works fine for anything periodic which requires an efficient attachment engine

and I am by no means an "efficiency clown" - I employ whats easiest and fastest to use, and gets the job done in the fashion desired

[Vexorian]

Difference being that eventually, a system like TT, would become faster then a loop, after you have a few timers firing simultaneously (or so Cohadar claims)

In order to make all those TriggerEvaluates faster than no TriggerEvaluates at all, you would need a lot of instances, even then though overall processor time used would be shorter, it is yet to know whether the non-preemptiveness will make players perceive some some 'LAG' as in periodic frame freezes. When I tested in this computer, using a single timer for 1000 instances seemed worse than using 1000 timers for 1000 instances, the later had worse overal fps, but the low fps was constant, the former had a lot of fps variability, making it very annoying on the eye.

, is that all inaccuracy is the same, as such, the system is very precise; a loop suffers from both inaccuracy and lack of precision

Please explain.

--
So I just coded the fastest timer system on earth, (provided it is for people that are too lazy to write loops and the interval is constant and very short), however I am using a jasshelper version from the future:

JASS:

//Syntax is subject to change
module TimerLoop
    private static thisstruct array V
    private static integer  N = 0
    private static timer T = CreateTimer()

    static method doLoop takes nothing returns nothing
     local integer i = 0
        loop
            exitwhen i==.N
            if( not V[i].loopAction() ) then
                call V[i].destroy()
                set .N=.N-1
                set V[i]=V[.N]
            else
                set i=i+1
            endif
        endloop
        if (.N==0) then 
            call TimerStop(.T)
        endif
    endmethod

    method addToLoop takes nothing returns nothing
        if (.N == 0) then 
            call TimerStart(.T , 0.02, true, function thisstruct.doLoop )
        endif
        set .V[.N] = this
        set .N = .N + 1
    endmethod
endmodule

struct test
   unit u
   integer c

   method loopAction takes nothing returns boolean
       if ( GetUnitAbilityLevel(this.u, 'B001') < 1) then
           call KillUnit(this.u)
           return false
       endif

       set this.c = this.c  -1 
       if (this.c == 0) then
           return false
       endif
       return true
   endmethod
   implement TimerLoop


   static method create takes unit u, integer c returns nothing
    local test t = test.create()
       set t.u = u
       set t.c = c
       call t.addToLoop()
    return t
   endmethod


endstruct

// No trigger evaluate was used when compiling this struct

[FriendlyPsycho]

Originally Posted by Vexorian

however I am using a jasshelper version from the future

I hope the compile error issues are fix'd

module and implement look like very interesting features mmhhmmnn.

[akolyt0r]

implement textmacro cheat ?! LOL ^^
whats "module" for ?

[emjlr3]

single timer for 1000 instances seemed worse than using 1000 timers for 1000 instances

that is interesting - would you rather have a constant 40fps, or a constantly changing 40-45....

Please explain.

it was incorrect (both methods have mutually shitty precision and accuracy) - please disregard

btw what is TimerStop ?

[FriendlyPsycho]

Originally Posted by emjlr3

that is interesting - would you rather have a constant 40fps, or a constantly changing 40-45....

Actually, a constant fps is better. The latter is very very annoying and that makes it worse.

[emjlr3]

you can really see a difference between .025 and .04 in game?

wow

[Tyrande_ma3x]

> you can really see a difference between .025 and .04 in game?
So can I... 0.04 is a crappy period, I prefer 0.03125.

[Rising_Dusk]

Yeah, I can't see the difference between 0.05 and 0.025 on my computer.