System Timer Ticker

[Jesus4Lyf]

>Stop with the name calling.

Sowwy.

Lol yeah, it is slightly faster. But if you want speed and don't mind sacrificing the user interface, you need to look up Rapid Timers. It's what TT would look like if noone cared what "nice user interfaces" are.

I'm still hoping to find a way to implement the method in KT2 without sacrificing the UI.

PS. Linked lists are nice because they don't add any overhead to the main body. But you're right, they probably add an insignificant amount to adding/removing instances.

 

[Builder Bob]

Lol yeah, it is slightly faster. But if you want speed and don't mind sacrificing the user interface, you need to look up Rapid Timers. It's what TT would look like if noone cared what "nice user interfaces" are.

Looks interesting, and not that much harder to use than TT.
Seeing as you made GTrigger, I'd think you'd approve of Rapid Timers. Too many spell casting triggers never wore down a map on it's own, but you bothered making it faster anyway. I think it's a good thing. Every little bit helps.

 

[Jesus4Lyf]

Yes and no. I don't approve of Rapid Timers because it doesn't allow period specification, and because KT1 is faster, probably. Rapid Timers is 15% faster than KT2 and TT at about 36,800 executions per second (over about 32,000, these numbers are off memory, btw), but KT1 is way faster at about 60,000 executions per second (eh, see KT2 thead. Just released more detailed test results yesterday...). RT is only that much faster at 100 executions, it has a large overhead, and may be slower than both TT and KT2 at a smaller number of instances anyway (pending bench tests). KT2 is still faster (as admitted by the author of Rapid Timers) for multiple periods, because of the overhead.

GTrigger was not released for the sake of extra efficiency, although it acomplishes this very well. It was written because:

• I hated the idea of spawning 12-16 events for each spell I made where the was an alternative.
• I liked the idea of a substitute event system that reduces code, and it makes code much nicer.
• It's faster to code with.
• You can declare a trigger in one line without storing it in a variable.
• It is minimalistic in every way (except internal implementation).

Note that in-game efficiency doesn't even come into it! Rapid Timers does not acomplish these kinds of things, but TT/KT2 do. And the speed difference is not useful. If it was, you'd use KT1 or a struct/stack loop.

See, either TT or KT2 is a much nicer interface than attaching to timers directly. Rapid Timers is not.

However, Rapid Timers is definitely nice for those who are obsessive about efficiency, like seemingly, yourself. Which is fine! I used to be too. I just wouldn't wish that kind of interface on every JASSer. Cohadar is very right in saying that maps don't suffer for efficiency as much as suckyness.

I dare say you would never notice the speed bonus from switching from TT to Rapid Timers, and KT2 is faster at what it does anyway.

I'm investigating a way of implementing Rapid Timers style internal implementation without losing the clean interface.

Edit:
Nearly there, I think.

 

[Tyrande_ma3x]

I dare say you would never notice the speed bonus from switching to any system

Fixed.

I have no idea why everybody is so crazy with all those systems and "which is faster by 296969%". Like, you're going to notice something that would happen a microsecond later? When the hell are you going to execute something 30k times to understand it is "slow"? It's efficiency and ease of use that matters - the system must work at all cost and never break down. That's why I prefer cohadar's resources - created exactly for the user and really efficient.

 

[Jesus4Lyf]

Precisely.

However, I must insist that there are exceptions to your rule. If you have 50 special effects all moving around, you can definitely experience lag. My point was you then wouldn't jump to Rapid Timers, you'd jump to a struct/stack loop manually coded, or KT1 which is the very same.

>I have no idea why everybody is so crazy with all those systems and "which is faster by 296969%".

Please understand that my bench tests are for the curious. I would not say a system should be used simply because it is fastest, hence why I wouldn't go the way of Rapid Timers.

You've summed it up very nicely there. And I agree that Cohadar has the right idea, and I've adopted that idea that the interface (and a reasonably high efficiency, and brilliant stability) is what actually matters.

 

[Tyrande_ma3x]

> If you have 50 special effects all moving around... you'd jump to a struct/stack loop manually coded, or KT1 which is the very same.
The effects would cause the lag, not the 50 timers... I'd reduce the eyecandy by a lot. But yes, I'll maybe use a single timer to run all this.

> Please understand that my bench tests are for the curious.
Agree. I was curious as well, good job for taking your time and testing these systems.

 

[Jesus4Lyf]

>Agree. I was curious as well, good job for taking your time and testing these systems.

Hey, thanks. I appreciate your appreciation.

>The effects would cause the lag

You know, you'd be suprised, and that's an all-to-common misconception. Originally Sharl and Sandman were written with a nasty old version of KT2, and they lagged. Now they don't. The effects were not the problem, even though they had hundreds of dummy units with attached effects on the screen (well Sharl did, but Sandman only had 40 per instance). Only the efficiency of the timer system changed.

By the way, I would actually encourage spell makers to add simple eyecandy like the sparks in Sharl (and spam it), because TT and KT2 handle these amazingly efficiently. Adding those things now brings close to no efficiency penalty! Especially because these systems extend their executions per second with the number of instances on a single period!

 

[Tyrande_ma3x]

> Now they don't. The effects were not the problem,
Really? And why does my computer go from 64 (should be 60) to 35 fps with a PC bought before 2 months? Still, it is more efficient to handle it on one timer than tens/hundreds.

 

[Jesus4Lyf]

Well my 3 year old laptop used to go from ~35 fps down to 10.
I suppose my point is they're now actually usable in a map.

Oh, and just for kicks:
Designing for People Who Have Better Things To Do With Their Lives (lol don't go read the whole doc, just the first few lines...)

Edit:
Anyone using Rapid Timers as a result of the discussion in this thread should switch to KT2 immediately (as they'd only have switched for efficiency), which is now faster and has nearly the same interface as TT.

Cohadar, as for upgrading TT, I don't know if you will or not, due to incompatability issues. My bet, I suppose, would be that you won't, or you'll try really hard to find some way to keep compatability...

Screws and nails...
(Do we need more snails? XD)

 

[Vexorian]

Eww Cohadar, was there really a good reason at all to add that StartEx function? It sounds like you just implanted a hash in there but instead of the usual, fast method you used TriggerEvaluate for loading the index (plus there's "timer indexing" on it, yiuck)

Was the reason just so you could say that TT supports flexible expiration times?

 

[Cohadar]

Was the reason just so you could say that TT supports flexible expiration times?

Of course not.
The reason was me wanting to use same TT_GetData() function no matter what kind of timers it runs on in the background.

Interface awesomness was always my primary goal.
What happens in the background is irrelevant.

 

[Doom-Angel]

a few questions:
is it possible to make the function Start or StartEx return boolean or any other type to let know when it's finished?

is it possible to use it in a loop? (also explain me why not cause im not sure i relized how it works)

is it possible to change periodic from the UserFunc?

i know those questions are will probably be answered with "no" but i wonder as well if it's possibly avilable with a few adjustments

also i wanted to ask - how come your start function takes integer as data instead of struct? just curious to know

 

[wraithseeker]

Actions that you run must return boolean with this to be with.

It is possible to use in a loop.

No, you have to start it over again with a new Timer.

 

[Doom-Angel]

>Actions that you run must return boolean with this to be with.
im not talking about the UserFunc im talking about the start function
for example:

boolean b = TT_StartEx(UserFunc,struct,period)

and thanks for the rest

 

[Flare]

also i wanted to ask - how come your start function takes integer as data instead of struct? just curious to know

A struct instance is just an integer that is used for an array index

local StructName data = ...
set data.member = value

would be equivalent to

local integer data = ...
set struct_StructName_member[data] = value

If it took a struct type, then it would be specific to that struct e.g. you wouldn't be able to pass a struct of type StructB if the parameter required a struct of type StructA (I believe you'd get "<variable> is not of type StructA" error)

im not talking about the UserFunc im talking about the start function

You want it to return a boolean when userFunc has stopped being executed, or return true if TT_Start(Ex) finished successfully? If it's the first, why would you need that? You'd already know when userFunc finished executing (since you'd have a function that is used by TT and returns true at some point) and you could do what you want with it from there

 

[Doom-Angel]

>You want it to return a boolean when userFunc has stopped being executed, or return true if TT_Start(Ex) finished successfully?

i want it to return true when it's finished successfully

thanks for the explanation about the struct as integer

 

[wraithseeker]

If what I think is correct for example

function test takes nothing returns boolean // this is the callback function and must return boolean
// your attaching stuffs and actions
if return == true then
return true // this would mean that the action is done and it is successful and the timer has stopped running.
else
return false // continue on..
endfunction

Handwritten and expect errors.

 

[Doom-Angel]

^ im not sure i understand where should i put it

and also im pretty sure this is not possible:

if return == true then

 

[wraithseeker]

this is just a test variable.

it should be a

local boolean test

Well, since it's a test, it doesn't matter right

Put the return false at the end of the condition and use a boolean to check whether the function has met your requirements aka conditions and then type return true.

 

[Doom-Angel]

^ im not sure if i understood your idea but if i did i think using a global would be better to let me know if it's finished....