Benchmark GetUnitUserData vs LoadInteger

[Lyerae]

I just said something about it in the JassHelper topic. Maybe he'll find it interesting.

 

[TriggerHappy]

It's most likely been proposed before, but good luck.

 

[weaaddar]

Almost every type is supported in the hashtable (code isn't but neither is code[]), and really the jagged array notation [x,y] is also valid. vJass already supports 2d arrays, they are faster then hashtables. The only reason to want hts is if you have a huge amount of elements but a future version of Vjass will translate huge arrays of non-handles to hashtables.

 

[Zwiebelchen]

So Loading from a hashtable takes less than twice the time of loading from UnitUserData? Say what you want, but: This is amazing. I never knew hashtables are THAT fast. I always compared them to some kind of "speeded up gamecaches", but this is so wrong.

I'm not one of those speed junkies. I prefer easier code over speed, usually. Though I personally like Indexing systems better than hashtables (because they tend to be easier in use), I use hashtables anywhere else, where indexing doesnt help.

Hashtables are awesome, alone for the fact, that they are quire simple to use. And they are not THAT slow too. I don't understand why people are so addicted in finding ways to avoid hashtables just to save some nanoseconds of processing power while doubling the code's size.

 

[Azlier]

Actually, this could actually prove that GetUnitUserData is slow along with hashtables. It proves one or the other.

 

[kingkingyyk3]

So, it is O(1),

 

[Weep]

How does GetUnitAbilityLevel() compare?

 

[TriggerHappy]

GetUnitAbilityLevel: 3.492
LoadInteger: 6.421.

LoadInteger is probably only slower because of GetHandleId. So depending on your scenario, each would be different.

Lets say you already know the units handle id (static units), then LoadInteger would be a better choice. Not to mention you need to actually save the units level with SaveInteger, but it wouldn't matter depending on how often it's called.

Overall, I think GetUnitAbilityLevel would be better suited, because it's all automated while with hashtables you have to deal with a lot of extra things.

Benchmark script is here btw.

 

[Jesus4Lyf]

So Loading from a hashtable takes less than twice the time of loading from UnitUserData? Say what you want, but: This is amazing. I never knew hashtables are THAT fast. I always compared them to some kind of "speeded up gamecaches", but this is so wrong.

I'm not one of those speed junkies. I prefer easier code over speed, usually. Though I personally like Indexing systems better than hashtables (because they tend to be easier in use), I use hashtables anywhere else, where indexing doesnt help.

Hashtables are awesome, alone for the fact, that they are quire simple to use. And they are not THAT slow too. I don't understand why people are so addicted in finding ways to avoid hashtables just to save some nanoseconds of processing power while doubling the code's size.

Good conclusion.

TriggerHappy, feel free to post up those benchmarks if you like... It'll be good to get some benchmarks up.

Basically, UnitData is real nice, sure. But hashtables are nice too. I have no idea what GetTriggerUnit- was talking about, since the point of indexing is associating a unique number with a unit so you can use arrays, basically.

 

[Anachron]

You should make a benchmark for the wc3c standard too: AutoIndex.

 

[Azlier]

It'll be the same considering that GetUnitId inlines to GetUnitUserData. With the right constants flipped, that is.

 

[Anachron]

Aww right, I forgot AutoIndex is just an hook.