One timer is cool and all

[Troll-Brain]

That ... is def not what I'm doing.

That uses multiple timers.. 1 timer per period.

Mine uses 1 timer for all periods. Mine has 1 timer for an entire map, not 2, not 3, just 1.

Try again =)

Ok, but i think this idea is silly.

As far as your data attachment, it's slower... it would run 2 evaluations instead of 1 for each evaluation, lol. I tried that before on attempt #3 and it failed utterly ^_^.

So yea, for your data attachment, you made the same mistake I made when I did attempt #3 =p

So yea yea, try again u =p

And how did you perform the test, note when it start to lag ?
Because i can't believe a trigger evaluation on an event fire is the same as a trigger evaluation with TriggerEvaluate.

And hashtables should not be used as this is supposed to be fast action ><

They are about only 1.7 time slower than a global array variable, sure it will kill your map
Against no pratical limitations that is really irrevelant.
Anyway it is eventual, i don't think i will use them. (expect for the boolexpr thing to avoid create/destroy them each time)

 

[Darthfett]

They are about only 1.7 time slower than a global array variable, sure it will kill your map
Against no pratical limitations that is really irrevelant.
Anyway it is eventual, i don't think i will use them. (expect for the boolexpr thing to avoid create/destroy them each time)

When we're talking about the most efficient a system could possibly be, this is a huge factor. Are you seriously going to say that even though we're trying to find the most efficient method to evaluate a function with passed data, that it doesn't matter if you're using globals or hashtables?

The speed gains are already insignificant, what you're suggesting is akin to benchmarking a $2000 computer while running programs.

When it comes to these sorts of things, I have little interest. The speed gains are too insignificant, and they don't make up for the user-interface. I am not planning on creating a second struct in order to have two periodic methods. TU is good because it is similar to the native way of writing code, while still recycling timers and having good speed.

 

[Troll-Brain]

When we're talking about the most efficient a system could possibly be, this is a huge factor. Are you seriously going to say that even though we're trying to find the most efficient method to evaluate a function with passed data, that it doesn't matter if you're using globals or hashtables?

No ?
I just say it wouldn't be noticeable and can remove all limitations, but as i said i think i won't use it because in fact for my personnal use (and it will be for ever a personnal thing) the limitations will be something theoric and never reached in practical.

The speed gains are already insignificant, what you're suggesting is akin to benchmarking a $2000 computer while running programs.

I don't really understand what you want mean.

When it comes to these sorts of things, I have little interest. The speed gains are too insignificant, and they don't make up for the user-interface. I am not planning on creating a second struct in order to have two periodic methods. TU is good because it is similar to the native way of writing code, while still recycling timers and having good speed.

That's your choice.
Did i already say it will be something personnal ?

 

[Nestharus]

Actually, I HAD A BRILLIANT IDEA ^_^.

A required definition for setting up a stream. What it'll do is increase the index so that data can be retrieved. In this way, as long as conditions are run in the order that they are added, everything can be put on the same trigger and one evaluation can be run ^_^.

This should be as fast as possible, but I'm really unsure whether the task manager in this design is faster than the tasking of plain old timers ^_^.

 

[Nestharus]

Working on my brilliant idea. So far I got it working, but I'm working on an updated task list that's more than 2x faster too ^_^.


Once the new task list is done, we can compare it to Timer task list ^^

New task list only has one loop instead of 2 =).


I suppose one way to test would be to see the offset of the timers as compared to a benchmark ^_^.

Timer after 1 second-
Timer- 1.25
KT2- 1.15
Super Streams of Uber Awesomeness- 1 .05


That's just an example. We shall see ^^.

 

[Jesus4Lyf]

For high class JASSers I recommend T32 for all things periodic and TU for all waits.
=_= I does not use TU-like systems more, because of my laziness to type NewTimer(), ReleaseTimer(), nulling variables, SetTimerData(). KT2-like systems is my cup of tea.

Lol, you know, I'm actually the same? I use KT2 and T32. XD

Nestharus, if it doesn't beat TU and T32 respectively, you're already losing the game.

 

[Nestharus]

j4l, the current version (actual running) is a little faster than regular timers, but radical for data attachment and retrieval =), meaning that it beats out TU but not KT2 or T32 at all ; O.

The current version with a single timer is faster than T32 : (. With multiple of the same period, it's the same speed : O. With multiple of different periods, I'm not sure if it's as fast as KT2 or not ; (.

I think the only difference between it and KT2 at this point is that it uses a single timer and thus has a loop for task management (when timers run etc). The question is, is a C++ timer faster or is my pimping JASS timer faster : P.

The only way to test it is when I finish it and benchmark them.

What I'll do is start up multiple periods and every second I'll check the benchmark. The one that lags behind the most loses =P.

 

[Jesus4Lyf]

>The current version with a single timer is faster than T32
What?

>What I'll do is start up multiple periods and every second I'll check the benchmark. The one that lags behind the most loses =P.
What?

 

[Nestharus]

Talking about 4.1, which isn't released =)


A single timer in 4.1 is exactly like T32, except that it doesn't have .next/.previous lol =P.


All it is is one trigger with conditions added on ^_^.

Many timers with the same period just add on to the first trigger, so it's just a trigger evaluation =P.

Many timers with different periods are similar to KT2 except that it all runs on one timer instead of multiple using a better top secret task manager : o.

The newest task manager for timers might be faster than regular timers, but I don't know : (. It'll have to be tested.


Now, it does not treat low periods and high periods differently. It only has one stream (I didn't see a point to many, and the new task manager is pretty epic ^_^)

Now, 4.1 will get released for testing and benchmarking etc when I get its task manager finished ^^

 

[Nestharus]

I don't think 4.3 can be made any faster : |...


What did I learn from this endeavor? There's just no way to beat wc3's Timer Tasking : (.

/bah

The most I can do is take out the run stack and just run it thru timers.. it has faster data retrieval and what not.. it also merges common periods together (if they have a birth time within the specified precision and they have the same period, they'll merge).

Yea... lots of cool stuff : (... too bad my Run Stack failz compared to wc3's... unless there is a way to improve it more.. wc3's timer stack is 100x faster than mine : (.

Oh well, I guess I proved it can be done at the least ^^