Let me give you a morning lecture about the difference between Indexing and Hashtable (well, it's morning at my time).
INTRODUCTIONSBoth method (Indexing and Hashtable) uses arrays in the process. Indexing is a 1D array (Unit[0]) while Hashtable is a 2D arrays (Unit[0][0]) which uses child key and parent key to determine which unit is which while Indexing uses only 1 key (Integer) to assign a value (Index) to a unit.
HASHTABLEBy using this method, it allows you to overwrite a data to a certain unit, it is useful enough if you're making a trigger that needs to be overwritten, for example, a buff trigger. Well, you know that buffs are reset each time you are affected to it while it's still on that unit, right ? For instance, you have Roar buff that lasts for 10 seconds. At the last remaining 3 seconds, you would cast Roar again, what would happen ? Ah yes, the buff is reset to 10 seconds, right ? This is where Hashtable comes in handy.
It also allows you to use a Direct Search Algorithm which would speed up the performance compared to Indexing which uses Binary Search Algorithm - the larger the index , the heavier the process (it depends on the object's index value too).
Hashtable can save values (Integer, Real, Boolean, etc) to an object that does not even exist in the map. Let's say you want to save a value of '200' to Item A, so when you pick up Item A (not initially on the map), and once you load to the correct path, you will get the 200 value from that Item. Basically, hashtable saves value to that Item Type, which will affect the Item associated with it.
INDEXINGThe main difference between Indexing and Hashtable, is that Indexing allows you to stack a data to a single object while Hashtable overwrites it. Imagine you have a spell that deals 50 damage per second when applied to a target unit and lasts for 10 seconds. Let's say you have 3 units having this ability and all of them cast at separately at interval of 1 second each. The damage dealt to that unit per second would (50 + 50 + 50) 150 damage per second, and each of the duration has its own timer. Like for the first cast, it would lasts 10 seconds, while the second cast would end 9 seconds after first cast, while the third cast would end 8 seconds after first cast.
Indexing as I said, uses a Binary Search Algorithm, it will loop until you hit the correct index value. Imagine your object has index value of 30, meaning that it will loop 30 times before it finds the index value for it, you can terminate the loop by setting the current looping integer to maxIndex.
It is faster than Hashtable because the fact it is only 1D array compared to 2D array (Hashtable). The Binary Search Algorithm can be ignored if compared to arrays that has different dimensions.
Looping through all indices on a timer is a fine thing, but when it comes to search which object is which, indexing is bad.
Of course, hence why I said it depends on the situation. That said, I rarely want to do that with anything other than timers, in which case I just attach a struct to the timer with TimerUtils since it's easier.
I would either just have the extra fields even when I wasn't using them, or (in vJass) have a place to attach a struct with additional data.
No (thank god).
What is this supposed to do? Just use hashtables.
You can still use hashtables in vJass.
(correct me if Im wrong) and other uses arrays. It doesnt matter how you do it as long as it works, really even you were talking about performence difference, all I can say is wtf? one eye blink takes so long I could add values to thousands of childkeys in same parent key in one hashtable and difference between calling SaveWhatEver and set whatever[index] is like what, 0.0001 second? lol
edo494 said:
globals
real array x
endglobals
function Test takes nothing returns nothing
set x[1000] = 5
endfunctionGetHandleId(h) - 0x100000)
This should not be true.
That's how many elements it initializes (since GUI tries to avoid forcing the user to create most objects explicitly). The array max size is 8192. That said, warcraft 3 doesn't allocate all the memory for the array at once; it increases its size as needed (by powers of 2, if I recall correctly).
