Timers vs "Magic Timers"

Clearly timers win.
proofe something against it xD.

why ?
1) theorie

self starting timer + TriggerEvaluate() against native "timers ticks" + ~ in speed something similar to TriggerEvaluate() (but faster due no need to read trigger from an array).

2) practise

"Magic Timer"

now how to test ? simple... set this TEST functions on a cinematic skipped event and also enter in chat "/fps" (so you can see the FPS drop)

and now push Esc to the point the FPS frops below ~60 FPS and count how many times you pushed Esc to achive that.

and yes in my case native timers are at least 1.5 times "faster" than the magic ones.

and in truth it's not a suprise. it was clearly obvious but well.
// if add callbacks the situation will be not much better xD

this thread was created cause the privious one was closed.

Timers are slower than MagicTimers? Thanks for pointing out exactly what I said in the magic timers thread.

0.001 is unrealistic as heck anyways.

Magic timers were created for larger time intervals.

for 0.001 a single timer + a loop is enough.

.

If you were trying to debunk what I said about heaps in the last part of the thread: Congratulations! You just pulled out a Stawman fallacy! You should be proud of yourself.


Actually, I am pleasantly surprised. This means MagicTimers are much faster than I thought! Note that to make the comparison fair, your timers need a callback and to use some sort of attaching system.

I now actually think MagicTimers are the best alternative to attaching.- easy to use, OOP and fast! , all thanks to your post, thanks TC!

learn to read first.
no i simply pointing what you told crap in the IsUnitDeadBX() thread. thats all.

any native function > jass one.


in truth MagicTimers are "Just another theorie system"

i though for 0.001 interval we should use animation timer instead if magic timer?

I suggest you read my post in that IsUnitDeadBX thread. If you don't understand it, read it again, continue looping until you actually understand it. For starters , what I said had nothing to do with TriggerEvaluate().

For example, what I proposed has nothing to do with this.

Are you suggesting we shouldn't use your custom hash/CSData clone and we should try gamecache instead?

Speaking of theory, your at least is quite an ambiguous conclussion for an experiment.



---
Edit:
Actually TC, this thread is very lame, I am actually disappointed... I'll try to put it in perspective for you. Imagine I did this:

- First I would test your SetDataBX in an environment with 147438 handles.
- Will point out how it fails absurdly in that case.
- Then I will conclude DataBX is another theory function.
- Will also point out how native gamecache beats your DataBX since it can stand that large quantity of handles.
. And therefore, based on how much DataBX blows I will conclude that all you said about "preloading 6K timers" in the DeadBX thread is crap.

As a translation, let's call your experiment E1, and my new experiment E2, I will explain the similarities to you.

1. Both are testing a system (MagicTimers, DataBX) against something that they weren't designed for. MagicTimers was never meant to be a replacement for timers, and they weren't meant for such crazy low intervals as 0.001seconds, on the other hand DataBX was never meant to support more than 15*8191 handles.

2. Both use the conclussion from #1, to demonstrate how a post that is totally unrelated to the systems in question, is wrong.

Whatever, Vex, if you want to keep bickering over this it's your choice.

He would continue the argument in another thread anyways.

yes.

so why did you mentioned them (not directly but the using heap heap with 2 timers) ??? i and grim was talking about x period and x instances !? and second anyway simple timer + wise attachment will be faster than magic timer. (it's simply a fact). and third yes of XAT is also just another theory system i never wrote what it's mega imba and use it everywhere. BUT cause i "created" it i use it if i really need to attach data (if no other ways are possible or more optimal ways) + i don't really like string abusing -> cache. for such purporses. (+ i will be slower).

and ! i forget to mention simple handle allocation don't really get slow. string allocation getting really slow... with "simple" handles i think it's similar to jass arrays aka it does extend the hash table after it reaches the 2^x limit.
aka alot of handles does slow handle allocation = myth
to make proper test allocate locations or triggers...

so this post and thread is related from your post of kind "we are stupid cause we don't use 2 timers and a heap".

yes we are mindless zombies and we should use some of this one certainly...

and thats kind of problem "influence"... but well it's not related to this thread xD.

btw what was the reason for creating magic timers ?! to make stuff oo ?
i think i know why...
old system has create separate timer and attached data for it and after it expires some actions were done (some projectile sys)
after some one (maybe iNfraNe or Anitarf or some one idk) have the idea to make all operation in 1 timer call back via loop... so impression was created what separate timer runnig is slow... (but in truth it the execution of callback function) after that "knowledge" you (and maybe some one else) have the idea to use it and create better timer system. and etc.
int truth it's kind a confusion. and with out a doubt it was a great toy for you to develop this system =) (i know it self).


btw :P XAT can handle 155446 handle difference etc. it simply MAY (but no must) fail aka will not have place to store data =)
but thats not the point. your post (in the other thread) may confuse some more unexpirienced users so they may think "omg! magic timers rocks and native timers suck !" it's really so. i have seen so much similar situations. it's called missunderstanding of information =) cause for example you can't convince me in such doubtful case.
damn again TT.
ok conclusion.

XAT suck.
MagicTimers suck.
Timers OK.
and let go home xD

The heap is at least as fast as your timer pool + H2I magic timers' slowness is due to trigger evaluate and function calls.

If you make a low level heap, you can achieve something that's at least as fast as a timer pool, but without the handle consumption.



It looks like you are the only guy that's confused here, I said "think of magic timers but without TriggerEvaluate and extra function calls" I did not say "use magic timers instead of native timers".

MagicTimers do rock though, native timers don't suck. MagicTimers are not meant to replace native timers but to replace attaching to timers in situations where the wait time is large, and using extra timers is likely to just make the handle count larger for no reason, I even said so in the first part of the place where I posted MagicTimers.



That was my idea dude.


It is sort of like that.

So magic timers aren't much slower than timer + attachment system, but for someone with OOP mentality they are way easier to use. And you end up not flooding the engine with more handles than necessary. That was the plan.

I myself would just implement a low level heap to get rid of the TriggerEvaluate deal.



Exactly, that's not the point.

Animation Timers follow the same idea of making stuff easy and not use more than one timer as magic timers but they are meant for short timer spawns where the order doesn't matter. AnimationTimers and MagicTimers are complementary systems and it is better not to test MagicTimers on something that AnimationTimers were meant for. That's what zen said, he did not said he actually uses AnimationTimers or that people should use it.


They already tested in some other thread that the allocator is not O(1). If you have proof against so then go ahead and post it somewhere.

Now that I got your reply and it looks like you actually understood what you did wrong in this thread. I am closing it.