System Key Timers 2

[Romek]

Could you upload your benchmarking script/map?

Also, what are those benchmarks for? Start/Add, GetData, etc?

 

[Jesus4Lyf]

>Could you upload your benchmarking script/map?

Happy to. But I'll need to take them down after a few days unless you can give me more attachment space on TheHelper. Note that these tests are exactly the same as included in post #2 anyway, just with the system switched or minor modifications to the user func.

>Also, what are those benchmarks for? Start/Add, GetData, etc?

They're actually for the total execution rate... IE how fast can you execute these systems for x instances with a period of 0.0, just running simple code to test if the attached data is correct (so GetData and the internal loop is all included).

Count the executions for 10 seconds, then divide them by 10 to get execs/sec.

Usually I run the test about 15 times and take the average, and note the margin of error.

Note that for TT, I manually forced the period to 0.0 instead of using the constant. Using the constant seemed to fatal error. The only other difference was making the init public so I could be sure it was called before the test. KT2 didn't need to be modified at all to support 0.0 period.

The Add/Start or return true speed isn't important compared to the looping speed, so I haven't tested that since writing the original doc.

-- Bench tests removed, as I ran out of attachment space --

 

[Cohadar]

This means only one TriggerEvaluate per procurement of a period. :nuts: Kind of a O(1) complexity loop (kind of).

No it is not.
You still have to run all the same code.
The creation/destruction of boolexprs is same thing as TriggerAddCondition and TriggerClearConditions
And O(1) complexity loop is either not a loop or it is oxymoron (kind of )

Anyways I would prefer if you did your tests on some normal period (0.04 perhaps?)

 

[Jesus4Lyf]

It's many less TriggerEvaluates. You can see why this system is faster.

>Anyways I would prefer if you did your tests on some normal period (0.04 perhaps?)

I think I actually can, just for comparing multi-instancing systems... But not for a while. Captain Griffen prooved Rapid Timers is faster than TT anyway, so KT2 is, in turn, also faster, but by a bigger margin apparently, because it's more efficiently implemented.

I may revisit this. But it's pretty clear KT2 is faster. And it makes sense.

Oh, and I'd use 0.03125, which KT2 now supports.

 

[Cohadar]

It's many less TriggerEvaluates. You can see why this system is faster.

Captain Griffen prooved Rapid Timers is faster than TT

No I can't see because like I said you just moved TriggerEvaluate to Boolexpr evaluate which is the same.

And even if Griffen's system(which isn't his system but a shameless TT ripoff) was much faster than TT (which it isn't) it would still be a piece of crap.

The difference between TT and all other similars is that TT does not have insane Cons lists.
And no benchmark will ever change that.

I also must notice that Griffein's benchmark is much different than yours when it comes to RT which only firms my belief that people should not be trusted with benchmarking their own stuff.

 

[Jesus4Lyf]

So I guess now we know the measure of your personal bias - 0.5%

>So I can only presume you tested some "special cases"

My, how quickly things change. Oh, and do not accuse me of things like that without proving it, thanks. I have no reason to exaggurate or misinform, or make false claims, nor have I done so, and I have put a lot of work into creating reasonable, fair bench tests. If you weren't going to listen to the bench test unless it told you what you wanted to hear, why did you ask me to do it (and it took about 1-2 hours) in the first place?

I'm honestly suprised that you said
"you just moved TriggerEvaluate to Boolexpr evaluate which is the same"
in response to me saying
"The And boolexpr thing doesn't add efficiency ... I have attached all code to one trigger per period, instead of one trigger per piece of code attached. This means only one TriggerEvaluate per procurement of a period."

So I'll spell it out.

Spoiler

Here's the KT2 function that is called by the timer.

    private function KeyTimerLoop takes nothing returns nothing
        set t_id=R2I(TimerGetTimeout(GetExpiredTimer())*800)
        set t_mem=KeyTimerListEndPointer[t_id]
        call TriggerEvaluate(TimerTrigger[t_id])
        set t_mem=0
        loop
            exitwhen t_mem==AddRemoveMax
            set t_mem=t_mem+1
            if IsAdd[t_mem] then
                set TriggerCond[ToAddMem[t_mem]]=TriggerAddCondition(TimerTrigger[t_id],Boolexpr[ToAddMem[t_mem]])
            else
                call TriggerRemoveCondition(TimerTrigger[t_id],ToRemove[t_mem])
                call DestroyBoolExpr(ToDestroy[t_mem])
            endif
        endloop
        set AddRemoveMax=0
        set t_id=-1
    endfunction

Here is what TT calls.

private function HF_Handler takes nothing returns nothing
    local trigger swap
    local integer i = HF_Counter
    loop
        exitwhen i<=0
        set Data = HF_Dataz<i>
        if TriggerEvaluate(HF_Triggz<i>) then
            set swap = HF_Triggz<i>
            call TriggerClearConditions(swap)
            set HF_Triggz<i> = HF_Triggz[HF_Counter]
            set HF_Triggz[HF_Counter] = swap
            set HF_Dataz<i> = HF_Dataz[HF_Counter]
            set HF_Counter = HF_Counter - 1
        endif
        set i = i - 1
    endloop
    // who can guess why am I not nulling swap here?
endfunction</i></i></i></i></i>

Here is the part in which KT2 acomplishes the same thing.

set t_id=R2I(TimerGetTimeout(GetExpiredTimer())*800)
set t_mem=KeyTimerListEndPointer[t_id]
call TriggerEvaluate(TimerTrigger[t_id])
set t_mem=0
...
set t_id=-1

And the rest is only fired when code is added or removed. See the "O(1) complexity loop"? Good. (Please don't tell me it's not O(1), I already know, it's just a joke. My point is it only calls TriggerEvaluate once to call all the code.)

"How is this even possible?" I hear you asking if you followed so far. Look closely at the add function (or the bit of it that fires in the loop on certain conditions, it's gets a little tricky to follow well unless you're Captain Griffen and have written something very similar and know why it's written like that). You'll see this line...

set TriggerCond[a_mem]=TriggerAddCondition(TimerTrigger[a_id],Boolexpr[a_mem])

Note carefully that the condition is attached to TimerTrigger[a_id] not TimerTrigger[a_mem]. This means it is attaching to a trigger that belongs to the timer, not to the piece of code being attached. That's right, it attaches everything on the same trigger. So when you said
"The creation/destruction of boolexprs is same thing as TriggerAddCondition and TriggerClearConditions"
you're also wrong, because if I used TriggerClearConditions it would wipe out all the other code attached to that period.

Truly, if you implemented this method in TT (which you can't) it would look like this:

set TriggerCond[a_mem]=TriggerAddCondition(Trig,Boolexpr[a_mem])

With the single trigger, not being an array at all. In reality you could add the start of the loop and the end of the loop as header/footer conditions on the trigger, add a periodic event, and not have a timer at all (a timerless timer system). However, I assume this would be slower than firing off a timer and hardcoding the header/footer. It would definitely make it slower for attaching functions because you would have to remove/add the footer to keep the order the conditions are stored in correct.

The reason there is part of the add/remove code inside the timer loop is for the situation that you add/remove code from within the TriggerEvaluate statement, which can otherwise cause a fatal error. The way the Add mechanism works varies depending where you call it from.

>And even if Griffen's system(which isn't his system but a shameless TT ripoff) was much faster than TT (which it isn't) it would still be a piece of crap.

Don't gamble your credibility like that, which you so often do. Get a bench test and proove it. We bothered to, so you shouldn't make statements like that without any evidence, against statements that have been benchtested by two people using two different methods and found to be true. Rapid Timers is faster than TT for firing the loop. Simple.

>The difference between TT and all other similars is that TT does not have insane Cons lists.

So stop freaking out at finding that it's slow. And that's also why you can't take this speed upgrade.

>I also must notice that Griffein's benchmark is much different than yours when it comes to RT which only firms my belief that people should not be trusted with benchmarking their own stuff.

We both used very different methods, and found nearly the exact same percentage difference. He said 30% for 200 instances, I said 15% for 100 instances.

I'd love for someone else to bench test KT2 in an unbiased way, like Captain Griffen. I know he doesn't seem to have any personal issues with it, like a certain Vexorian who would even do what the documentation says explicitly not to do to say it's bad (when the results come back as expected).

>And O(1) complexity loop is either not a loop or it is oxymoron

Lol, there isn't a loop for firing the code anymore. That's my point.

I hope this clears things up.

 

[Sim]

Note by Daxtreme - Message to users replying in this thread: Please DO NOT reduce this thread into any kind of flamewar over benchtests. Thanks.

Yo "users", "contributors", "posters", AKA everyone. Stop it. Now.

If you don't like the benchtests, fine, but rage against them elsewhere. Or make some of your own. Or try to convince me that you're doing this "For great justice" (benchmarks...?) but just don't do it here.

So, please discuss KT2 and stop arguing about benchmarks which some might believe in, some do, and some obviously never will. I'd much rather see a nice discussion about "How it can be improved?" if it can, although that is probably too much to ask of this thread.

Yours,
Daxtreme

 

[Jesus4Lyf]

>I'd much rather see a nice discussion about "How it can be improved?"

Y'know, I don't even mind spell requests and assisting people in using the system. I think that's much more relevant. It would reveal how the system can be improved, if there are improvements to be made.

I'm happy with it's interface and where it's at, and it's speed. Discussion of things like spell requests or system requests or help in using it seems much more relevant.

If we can make this thread stop being technical, and welcome less experienced JASSers back in, that may help.

 

[Tyrande_ma3x]

> > Anyways I would prefer if you did your tests on some normal period (0.04 perhaps?)
Bench test this as a final and lets stop this arguing.

> so KT2 is, in turn, also faster, but by a bigger margin apparently, because it's more efficiently implemented.
Faster, yes, but not that efficient since it doesn't allow exact periods. Can't this be fixed somehow?

 

[Andrewgosu]

Not being disrespectful, or anything, but no matter which timer attaching system I use,... I fail to see the difference in speed.

I mean, the changes are so marginal.

Anyway, I'll award some reputation to the person who benchmarks TT, KT and timerUtils (both)
and makes a graph based on the data and posts it here.

 

[Cohadar]

>The difference between TT and all other similars is that TT does not have insane Cons lists.

So stop freaking out at finding that it's slow. And that's also why you can't take this speed upgrade.

First of all TT is not slow, second I am not freaking out but simply find it hard to believe in sudden benchmark jumps out of nowhere.

We both used very different methods, and found nearly the exact same percentage difference. He said 30% for 200 instances, I said 15% for 100 instances.

Err percantage is a relative category, number of instances has no effect on it.
So your results differ by 15% (a bit too much to be called objective difference)

And yes you both used very different methods, one that best suted your systems. That is exactly the reason people should not be allowed to benchmark their own.

The reason this is turning into a flame war is that you have done nothing in the past few days but keep claiming that TT is slow(which it isn't) and KT2 is "the fastest on earth" (The same thing is claimed in both RT and TimerUtils threads.)

I don't even mind that but your attention to prove that KT2 is better timer system than TT because it is faster (which it isn't by any margin that matters)

And like I said before you fail because in your chase for speed you (and many others) sacrifice usability.

So if you don't want me to "freak out" when you speak of speed, please don't freak out when I talk about other aspects.

 

[Romek]

> Anyway, I'll award some reputation to the person who benchmarks TT, KT and timerUtils (both)
You can't really compare TT and KT to TimerUtils.
They work in completely different ways. TU uses as many timers as it needs, with any frequency.

Anyway, I might benchmark these later, not for the reputation, but to end this debate.

Also Daxtreme, the reason why there are so many arguments is because Jesus4lyf made some pretty unrealistic claims which make TT look ridiculous, so naturally, Cohadar is defending his system.

 

[Jesus4Lyf]

>Faster, yes, but not that efficient since it doesn't allow exact periods. Can't this be fixed somehow?

As you know, KT2 supports down to 0.00125 granularity. It now automatically corrects periods by rounding them down to the nearest 0.00125, as well. I actually can fix it to allow any period! The reason I have not is that KT2 gains efficiency when a period is reused. This means I should encourage users to reuse periods, and hence why I'm happy to leave the granularity at 0.00125 (which is flexible enough for any reasonable period anyway).

If people seriously want/need the rest of the period restrictions removed, I'll consider it. But otherwise, it serves a purpose for efficiency. Let me know your thoughts.

>I'll award some reputation to the person who benchmarks TT, KT and timerUtils (both) and makes a graph based on the data and posts it here.

I'm happy to do this, but I'd like you to know that Vexorian would never agree that it's possible. My method for testing is setting the periods for the timer systems to 0.0, running them for 10 seconds with x instances of basic code attached, and then counting the executions per second. I repeat this about 15 times and take the average and log the margin of error (for each system). If you say that you're happy with this method (which is what I've used the whole time) then I will do this.

>I fail to see the difference in speed.

Fully agreed. I pitch KT2 on it's interface. It's efficiency is stated only for the curious.

Anyway, I might benchmark these later, not for the reputation, but to end this debate.

I'd love to see your results, and your test itself. ^_^

Edit:
Cohadar: Anyways I would prefer if you did your tests on some normal period (0.04 perhaps?)
Tyrande_ma3x: Bench test this as a final and lets stop this arguing.

I tried what Cohadar said for a test, 0.04 period. FOR COMPARING TT/KT2/RT I am able to use a much more stable and reliable method, because I can simply time from the start of the loop to the end of the loop, to compare these systems directly. Vexorian would agree on this (I expect). In fact, here's the damn tests, I don't wanna hear another thing about it. I didn't want to do this test, but I have done it with very careful precision to get people off my back. Read the code yourself, change it yourself, fix it if you think it's wrong, no matter what you do, KT2 just has the faster loop (I didn't try other numbers of instances. Feel free to do so for your own curiosity). This (unless I missed something really badly some how) is a perfectly fair test of the speed of the loops of the timers, and should be perfectly reliable.

Executions of the whole timer loop per second, for 100 instances, 5 tests to display margin of error as well as results:
483, 481, 483, 484, 484 - TT
680, 688, 684, 689, 680 - KT2
TT Average: 483 loops per second.
KT2 Average: 684.2 loops per second.

KT2 - 41.656% faster.

It's actually a fairer and more accurate result than my other tests. I REALLY don't want to hear anything about it. Read the test, understand it, and pretend you wrote it yourself. Rewrite it, write your own, do whatever you want. Just don't bring up this test, unless you can inform me of exactly what I've done wrong, and produce vastly differing results to demonstrate it.

Thank you, and may this bring some silence about speed.

 

[Romek]

Well, I tested it too, with your maps.
I got:
TT: ~650
KT: ~780
So KT is faster. I'm not sure about the 50% faster though.

Also, TT_Start is faster than KT_Add. Though that's not important.

 

[Jesus4Lyf]

Well, you got 20% faster, which is what I originally was saying anyway. Bench tests do that, though. Thanks for posting your results.

>Also, TT_Start is faster than KT_Add. Though that's not important.

Cool.

 

[Cohadar]

Well, I tested it too, with your maps.
I got:
TT: ~650
KT: ~780
So KT is faster. I'm not sure about the 50% faster though.

Amazing how this benchmark results jump up and down.
Lets try this with some "real life" tests for the last map.

Multi Instance Multi Execution Tests:

Spoiler

//========================================================================
// Make sure to set TT period constant for this test
// public constant real PERIOD = 0.04
//========================================================================    
scope TTBenchmark initializer Test 

globals
    integer Count=0
    real Last
    real Sum=0.0
endglobals

private struct Data
    integer ticks
    lightning light
    real x
    real y
    
    static method create takes nothing returns Data
        local Data data = Data.allocate()
        set data.ticks = R2I(10.0 / 0.04) // 10 seconds or 250 ticks
        set data.x = GetRandomReal(-1024.0 , 1024.0)
        set data.y = GetRandomReal(-1024.0 , 1024.0)
        set data.light = AddLightning("CLPB", true, 0, 0, data.x, data.y)
        return data
    endmethod
    
    method Tick takes nothing returns boolean
        set .x = .x + GetRandomReal(-64.0 , 64.0)
        set .y = .y + GetRandomReal(-64.0 , 64.0)
        call MoveLightning(.light, false, 0, 0, .x, .y)
        set .ticks = .ticks - 1
        return .ticks <= 0
    endmethod
    
    method onDestroy takes nothing returns nothing
        call DestroyLightning(.light)
    endmethod
endstruct

//==================================================================================
//  Generated functions
//==================================================================================
function DoExample0 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample1 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample2 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample3 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample4 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample5 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample6 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample7 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample8 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample9 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction


//========================================================================
    private function Test takes nothing returns nothing
        local integer i = 10
        
        loop
            set i = i - 1
            exitwhen i < 0
            call TT_Start(function DoExample0, Data.create())
            call TT_Start(function DoExample1, Data.create())
            call TT_Start(function DoExample2, Data.create())
            call TT_Start(function DoExample3, Data.create())
            call TT_Start(function DoExample4, Data.create())
            call TT_Start(function DoExample5, Data.create())
            call TT_Start(function DoExample6, Data.create())
            call TT_Start(function DoExample7, Data.create())
            call TT_Start(function DoExample8, Data.create())
            call TT_Start(function DoExample9, Data.create())
        endloop
            
    endfunction
endscope

scope KT2Benchmark initializer Test 

globals
    integer Count=0
    real Last
    real Sum=0.0
endglobals

private struct Data
    integer ticks
    lightning light
    real x
    real y
    
    static method create takes nothing returns Data
        local Data data = Data.allocate()
        set data.ticks = R2I(10.0 / 0.04) // 10 seconds or 250 ticks
        set data.x = GetRandomReal(-1024.0 , 1024.0)
        set data.y = GetRandomReal(-1024.0 , 1024.0)
        set data.light = AddLightning("CLPB", true, 0, 0, data.x, data.y)
        return data
    endmethod
    
    method Tick takes nothing returns boolean
        set .x = .x + GetRandomReal(-64.0 , 64.0)
        set .y = .y + GetRandomReal(-64.0 , 64.0)
        call MoveLightning(.light, false, 0, 0, .x, .y)
        set .ticks = .ticks - 1
        return .ticks <= 0
    endmethod
    
    method onDestroy takes nothing returns nothing
        call DestroyLightning(.light)
    endmethod
endstruct

//==================================================================================
//  Generated functions
//==================================================================================
function DoExample0 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample1 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample2 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample3 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample4 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample5 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample6 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample7 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample8 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample9 takes nothing returns boolean
    local Data data = KT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction


//========================================================================
    private function Test takes nothing returns nothing
        local integer i = 10
        
        call KT_Init() // use initializer keyword perhaps?
        
        loop
            set i = i - 1
            exitwhen i < 0    
            call KT_Add(function DoExample0, Data.create(), 0.04)
            call KT_Add(function DoExample1, Data.create(), 0.04)
            call KT_Add(function DoExample2, Data.create(), 0.04)
            call KT_Add(function DoExample3, Data.create(), 0.04)
            call KT_Add(function DoExample4, Data.create(), 0.04)
            call KT_Add(function DoExample5, Data.create(), 0.04)
            call KT_Add(function DoExample6, Data.create(), 0.04)
            call KT_Add(function DoExample7, Data.create(), 0.04)
            call KT_Add(function DoExample8, Data.create(), 0.04)
            call KT_Add(function DoExample9, Data.create(), 0.04)
        endloop
    endfunction
endscope

//========================================================================
// Make sure to set TT preload constant for this test
// private constant integer PRELOAD = 102
//========================================================================    
scope TTExBenchmark initializer Test 

globals
    integer Count=0
    real Last
    real Sum=0.0
endglobals

private struct Data
    integer ticks
    lightning light
    real x
    real y
    
    static method create takes nothing returns Data
        local Data data = Data.allocate()
        set data.ticks = R2I(10.0 / 0.04) // 10 seconds or 250 ticks
        set data.x = GetRandomReal(-1024.0 , 1024.0)
        set data.y = GetRandomReal(-1024.0 , 1024.0)
        set data.light = AddLightning("CLPB", true, 0, 0, data.x, data.y)
        return data
    endmethod
    
    method Tick takes nothing returns boolean
        set .x = .x + GetRandomReal(-64.0 , 64.0)
        set .y = .y + GetRandomReal(-64.0 , 64.0)
        call MoveLightning(.light, false, 0, 0, .x, .y)
        set .ticks = .ticks - 1
        return .ticks <= 0
    endmethod
    
    method onDestroy takes nothing returns nothing
        call DestroyLightning(.light)
    endmethod
endstruct

//==================================================================================
//  Generated functions
//==================================================================================
function DoExample0 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample1 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample2 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample3 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample4 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample5 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample6 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample7 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample8 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction

function DoExample9 takes nothing returns boolean
    local Data data = TT_GetData()
    if data.Tick() then
        call data.destroy()
        return true
    endif
    return false
endfunction


//========================================================================
    private function Test takes nothing returns nothing
        local integer i = 10
        
        loop
            set i = i - 1
            exitwhen i < 0
            call TT_StartEx(function DoExample0, Data.create(), 0.04)
            call TT_StartEx(function DoExample1, Data.create(), 0.04)
            call TT_StartEx(function DoExample2, Data.create(), 0.04)
            call TT_StartEx(function DoExample3, Data.create(), 0.04)
            call TT_StartEx(function DoExample4, Data.create(), 0.04)
            call TT_StartEx(function DoExample5, Data.create(), 0.04)
            call TT_StartEx(function DoExample6, Data.create(), 0.04)
            call TT_StartEx(function DoExample7, Data.create(), 0.04)
            call TT_StartEx(function DoExample8, Data.create(), 0.04)
            call TT_StartEx(function DoExample9, Data.create(), 0.04)            
        endloop
            
    endfunction
endscope

In case someone was wondering the tests simulate 10 spells with 10 instances all running at the same time.
So you should see 10x10 = 100 lightning effects in the map center jumping around randomly for 10 seconds.

 

[Jesus4Lyf]

You can't bench that because it uses TT_StartEx on a non 0.0 period (anyone following the bench tests so far will understand that). But that would be a nice test if it were possible. And KT2 would be faster by a smaller margin because the time it takes to execute the tick is the same for both systems, so the overhead diminishes by comparison and the percentage drops. Switch that test over to TT_Start instead and it can be tested (using the direct comparison method). Make Romek do it. I'm shouldn't because apparently you don't trust me anyway.

You may have noticed Romek's computer is a lot faster than mine. There's all kinds of reasons for bench marks to perform differently on different computers. Such as operating system or the amount of RAM it has, or maybe even how fast it's RAM is. My system only reads from one trigger, as you know.

By the way, KT_Init() was a modification for the test (although unneccessary - my thought was to make sure it fires before the scope initializer XD). The real system does use an initializer.

KT2 is clocking at at least 20% faster than TT, which is my "pretty unrealistic claims which make TT look ridiculous" (Romek) being proven now by 3 people (you can check with Captain Griffen as the third). I'm happy for people to upload the numbers they get from my last test maps, because undoubtedly they will vary. I wouldn't mind developing some sort of average.

Are we there yet? Lol.

 

[Romek]

Could you upload a map, Cohadar?

> Make Romek do it. I'm shouldn't because apparently you don't trust me anyway.
I've got other things to do at the moment, but I'll check it when I have time. Again.

> You may have noticed Romek's computer is a lot faster than mine.
My computers crap anyway. I don't think it matters too much anyway.

> Are we there yet? Lol.
Cohadar made a fair point about the tests all being done in unrealistic situations. So I don't think they're completely valid.
Feel free to post "KT2 is faster with one instance than TT" wherever you want though.

 

[Cohadar]

You can't bench that because it uses TT_StartEx on a non 0.0 period

Didn't cross my mind. I made those test in text editor.
(I can't test stuff myself because japi does not work on my machine)
Well it can be tested just not the way you did it, maybe later, TT_Start will have to do.

I'm shouldn't because apparently you don't trust me anyway.

I wouldn't trust myself with it.

You may have noticed Romek's computer is a lot faster than mine.

Once again, relative properties are not affected by absolute parameters.
Unless of course someone made a PC with KT2 chipset

By the way, KT_Init() was a modification for the test (although unneccessary - my thought was to make sure it fires before the scope initializer XD). The real system does use an initializer.

Vexorian would bitchslap you for that.

Could you upload a map, Cohadar?

Ok uploaded, make sure you save the maps before you run them.
I was not able to test them myself, just copied scripts over.

 

[Sim]

Nonetheless, the fact this supports multi-periods along with its speed is why I use it.

> Also Daxtreme, the reason why there are so many arguments is because Jesus4lyf made some pretty unrealistic claims which make TT look ridiculous, so naturally, Cohadar is defending his system.

Now I see.

May the discussion continue with the friendly tone noticed in the last few posts.