[vJASS] Trigger evaluations

[Garfield1337]

I've started working on a spell and I've got a question.
In this spell, there are multiple objects which i use structs for, however, the objects are very similar except each has a different method. This method should be, for each object type, executed each 0.03 seconds for which i use T32.
Now, i've got 2 ways of doing it and my question is which is better.

-I thought about using 1 struct that would have multiple methods, for each object type. Each instance of this struct would have a trigger member that would have one of these methods assigned as it's condition upon instance creation so i can evaluate the trigger member in a method ran by T32 to fire each instance's corresponding method.

-The second way would be to make a struct for each object type. While in this way, i would avoid trigger evaluations which are slow, as far as i know, i would also have to implement T32 in each struct which would make multiple loops and additional methods for each struct. Also the only difference between those structs would be 1 method :/

TL;DR Are trigger evaluations really that slow or it doesn't matter that much?

 

[Nestharus]

Are trigger evaluations really that slow or it doesn't matter that much?

For 32x a second, yes, it does matter a lot.


For 32x a second, a hashtable will die compared to an array just as a trigger evaluation will die compared to a function call. Surprisingly, a function call with no arguments and no return (or 1 argument) pretty much does as well as an inlined function ;P.

 

[Garfield1337]

Are you saying hashtables shouldn't be used for spells fired 32 times a second are as inefficient as using a trigger evaluation?

 

[Nestharus]

I'm not saying that at all ; )

I'm just saying that you shouldn't use either in a spell that fires so often.

 

[PurgeandFire]

It isn't super efficient, but it shouldn't have a noticeable difference on the game's speed or fps.

Generally, it depends on the functions called within the evaluation of whether or not it will slow down the speed. However, the evaluation itself is pretty fast, as long as the condition of the trigger returns false.

You probably shouldn't use it if you can avoid it, but otherwise it will still be okay to use, just as hashtables would be okay to use for a spell.

 

[Garfield1337]

I see.
Well, i'll not use them since i've got a workaround.

 

[Bribe]

Hashtables, from my tests, are about 4-6 times slower than arrays. If it's avoidable, avoid it, if it's not or it makes your life easier, just stick with them.

 

[Troll-Brain]

Hashtables, from my tests, are about 4-6 times slower than arrays. If it's avoidable, avoid it, if it's not or it makes your life easier, just stick with them.

Hmm, strange, i made one test long time ago with custom StopWatch natives and it was about 1.7 time slower (considering i used an hashtable as an array, which means with a constant argument and a variable one.)

Are you sure of that ?

 

[Justify]

Hashtables, from my tests, are about 4-6 times slower than arrays. If it's avoidable, avoid it, if it's not or it makes your life easier, just stick with them.

I bet there was something wrong. Like Troll said, Hahstables should be <2 times slower. The tests I saw said something about 60%.

 

[Bribe]

Stopwatch natives have shown me even up to 16 times slower when I've tested them in the past -_-

I guess we should upload a test map and settle this once and for all.

 

[Troll-Brain]

Problem is that stopwatch natives no longer works with the newest patchs, i dunno if we can really believe a stress test by checking how many fps we lost.
And i suppose we need to test it with the newest patch, just to be sure in case the hashtable efficiency has been changed.

I could be wrong but i hardly believe your statements Bribe, or at least it was not so poorly efficient few patchs before when i tested them. (or was i drunk ? hmm ... )

 

[Bribe]

I'll get a map together which deals in FPS-based testing. It's really the only way to do it. Even when they were "working", the Stopwatch natives returned some fairly arbitrary results at times and they couldn't be trusted.

 

[Garfield1337]

Sorry for bumping the thread, i thought it's appropriate to ask here since its evaluation related.
I noticed that once compiled, extended structs have trigger evaluations within their destructors that evaluate onDestroy methods. Will those evaluations have impact on efficiency, considering I'm not using onDestroy?

Generally, it depends on the functions called within the evaluation of whether or not it will slow down the speed. However, the evaluation itself is pretty fast, as long as the condition of the trigger returns false.

According to the above quote, it shouldn't since the triggers will have no conditions/onDestroy methods, though i need a confirmation.

 

[Nestharus]

Consider this-


10 triggers evaluated each with 1 condition is much slower than 1 trigger evaluated with 10 conditions.


This means that the trigger evaluation itself has quite a bit of overhead.


Also, the trigger evaluation from structs extending structs comes from polymorphism. Struct B might extend struct A but it might be stored in a struct A variable. When struct B's destructor is called (while it is sitting in struct A), it'll evaluate the trigger that'll send it to B's destructor and then to A's destructor rather than just calling A's destructor.

//B extends A
local B b = B.create()
local A a = b
call a.destroy() //calls B's destructor, then A's

A lot of people wonder why the trigger evaluation is in there. It's not because vexorian is crazy >: p.