Not directly to the point but might be interesting for those of you interested in hashtable internals:
Modern Dictionaries by Raymond Hettinger (python hashtables, history of different implementations, with analysis and good humor, highly recommended)
i know python dicts are a not the same as jass hashtables (API wise python is superior for sure, perf wise i'm not sure the comparisons are worth anything given jass vm overhead, but python is still prolyl better)
also i want to note i recently stumbled on a lecture about some JVM internals (sry can't seem to find the link right now) and there was a slide about how the call convention differs and for a small signature the assembly to do the conversion was like a full page of thick text. to think JASS does it that well is very optimistic, most likely in calls to most natives the overheads of the VM will drown out a lot of the actual costs.
also i have seen what a c++ vector for loop looks in inlined assembly before the optimiser kicks in and erases all of that crap, that slide of text was so thick it was unreadable.. ofc a good optimiser can strip out 90% of that but you should know the semantics is 100% of the code, that it shrinks to 10% or less is compiler heroics. not directly of relevance to jass loops or anything but it goes to show what looks like trivial bit of dirt on your screen or even something you don't realise you have written can really imply a lot of work.
Finally about hashtables once again. it is all nice and all to compare perf in a tight loop and it CAN give useful data.. however it can be quite misleading. the use cases for an array and hashtable are different.
an array is contiguous memory u can access by index, it is meant to be accessed by that index, and to be commonly iterated over, an excellent general purpose data structure you should use unless otherwise required. (also vjass structs are structore-of-arrays type of constructs, google that if you care, perf implications there both good and bad).
hashtables are essentialyl meant as mappings between 2 objects, they are dynamically sized and are not necessarily contiguous. they are NOT meant to be iterated over, they are meant to be queried for the value mapped for the key. the key might be reduced to an integer for jass case, (shitty api design for blizz..) but semantically that is just boilerplate.
if i want to do a reverse lookup for some value (eg player name) then with a hashtable i can do it with 1 hashtable lookup usually(99.999% of time kind of usually).
with an array i need to iterate over it do a lot if string comparisons till i find the right one, then i can return the player index.
if u benchmark "array vs hashtable" it may look like a hashtable is slower, but in reality it is often a trade off of
(linear search of array with a loop and expensive object equality comparisons ) OR a single lookup from hashtable. in this real scenario the slow hashtable often is equal or faster even if the implementation is slow. because it enables you to use a more efficcient lookup algorithm (for the hashtable case i would hesitate to even use the word algorithm since it is so simple) in addition the hashtable case in this case is much simpler and thus more bug resistant. simpler code is more often correct, hashtables help you write correct code, use them! (also might end up faster sometimes
)
Modern Dictionaries by Raymond Hettinger (python hashtables, history of different implementations, with analysis and good humor, highly recommended)
i know python dicts are a not the same as jass hashtables (API wise python is superior for sure, perf wise i'm not sure the comparisons are worth anything given jass vm overhead, but python is still prolyl better)
also i want to note i recently stumbled on a lecture about some JVM internals (sry can't seem to find the link right now) and there was a slide about how the call convention differs and for a small signature the assembly to do the conversion was like a full page of thick text. to think JASS does it that well is very optimistic, most likely in calls to most natives the overheads of the VM will drown out a lot of the actual costs.
also i have seen what a c++ vector for loop looks in inlined assembly before the optimiser kicks in and erases all of that crap, that slide of text was so thick it was unreadable.. ofc a good optimiser can strip out 90% of that but you should know the semantics is 100% of the code, that it shrinks to 10% or less is compiler heroics. not directly of relevance to jass loops or anything but it goes to show what looks like trivial bit of dirt on your screen or even something you don't realise you have written can really imply a lot of work.
Finally about hashtables once again. it is all nice and all to compare perf in a tight loop and it CAN give useful data.. however it can be quite misleading. the use cases for an array and hashtable are different.
an array is contiguous memory u can access by index, it is meant to be accessed by that index, and to be commonly iterated over, an excellent general purpose data structure you should use unless otherwise required. (also vjass structs are structore-of-arrays type of constructs, google that if you care, perf implications there both good and bad).
hashtables are essentialyl meant as mappings between 2 objects, they are dynamically sized and are not necessarily contiguous. they are NOT meant to be iterated over, they are meant to be queried for the value mapped for the key. the key might be reduced to an integer for jass case, (shitty api design for blizz..) but semantically that is just boilerplate.
if i want to do a reverse lookup for some value (eg player name) then with a hashtable i can do it with 1 hashtable lookup usually(99.999% of time kind of usually).
with an array i need to iterate over it do a lot if string comparisons till i find the right one, then i can return the player index.
if u benchmark "array vs hashtable" it may look like a hashtable is slower, but in reality it is often a trade off of
(linear search of array with a loop and expensive object equality comparisons ) OR a single lookup from hashtable. in this real scenario the slow hashtable often is equal or faster even if the implementation is slow. because it enables you to use a more efficcient lookup algorithm (for the hashtable case i would hesitate to even use the word algorithm since it is so simple) in addition the hashtable case in this case is much simpler and thus more bug resistant. simpler code is more often correct, hashtables help you write correct code, use them! (also might end up faster sometimes