But that's because TU is the only one they see in the jass section of forums like this.. see what I'm saying?
Well if it did matter that much i shouldn't have given up, the fact is no matter you like it or not, TU is a de facto standard.
If I wanted to use a timer system and I looked through the list and saw your well-documented, easy to understand script and I compared it to the following post which, let's just pretend vexorian posted, I'd definitely use yours.
I think that TU is documented enough, yes the static ifs seem eyesore and cumbersome for a vJass beginner, but when it's converted in jass, it's not.
Now, use Mag's version of TU is much better, because of the fix.
I think that Mag version should be ungraveyarded and explained why this version is better.
I think you assume people use libraries they are familiar with more than is true.
Yep, that's why it doesn't worth it.
But well, instead of the graveyard, maybe there should be a section for scripts that we could use in a personal resource, and not in a public one.
But that's their fault.. They post in the triggers and scripts section, we say "You instanciated a timer with TU and released it with TimerStack" and they look stupid, but learn from the mistake. Won't happen again.
I don't believe in humans that much, this "error" will pop up many times.
And again if you use TU and mine, you will "spam" timers for nothing.
Ah okay I understand what you meant there now. But what's the point? Why would you want to do that?
It's just to make the offset as the first handle id on an integer variable (first timer created), then you're sure that you will be able to use 8191 timers or less.
You don't have to define a constant.
Plus, it keeps the array size as low as possible (theorically use the array should be faster then)
Maybe you're right. Calling a jass function is probably not worth (maybe even slower) than just using CreateTimer() and DestroyTimer(). I guess we'd have to test that one to really know.
Another option would be to increment maxIndex, pause timer, and set timer=stack[index] manually, which would be
quite fast, but certainly would never be okay in a public resource.
---
Edit: I've tested it. Turns out the overhead for calling a custom jass function is nearly twice as efficient (can we actually say that?) as using Create/Destroy timer.
JASS:
scope createTimerVsCustomFunc initializer i
globals
private constant boolean DOING_CREATES=false //else, doing custom funcs
private constant real TIMEOUT=1./1000.
private constant integer COUNT=-2+200
endglobals
private function none takes nothing returns nothing
endfunction
private function creates takes nothing returns nothing
local integer index=0
loop
exitwhen index>(COUNT)
call DestroyTimer(CreateTimer())
set index=index+1
endloop
endfunction
private function customs takes nothing returns nothing
local integer index=0
loop
exitwhen index>(COUNT)
call none()
call none()
set index=index+1
endloop
endfunction
private function after takes nothing returns nothing
static if DOING_CREATES then
call TimerStart(GetExpiredTimer(),TIMEOUT,true,function creates)
else
call TimerStart(GetExpiredTimer(),TIMEOUT,true,function customs)
endif
endfunction
private function i takes nothing returns nothing
local timer time=CreateTimer()
call TimerStart(time,6.,false,function after)
set time=null
endfunction
endscope
At 100,000 executions per second, DestroyTimer(CreateTimer()) spiked to 35 fps and then oscillated between 45 and 55.
At 200,000 per second, none() none() spiked to 47 fps and then oscillated between 55 and 60.
I'll let you decide for yourself what that means, but in my book that's enough to make timer recycling worthwhile.
Your benchmark is totally flawed, because your custom function is empty.
Here is valid one in attachments.
Use the optimized maps, because the size name of variables, functions does matter.
Result : 25 fps for Create/Destroy and freez for timer recycling.
Note that's even an unrealistic case because here variable and function name are 1 character length where in a real optimized map it should be 2 or even 3.
It means that in a real map timer recycling would be even slower than it is here.
I'll let you decide for yourself what that means, but in my book that's clearly not enough to make timer recycling worthwhile.
