#Advantages of using the hash of an Animation vs storing a const string with the animation name?

1 messages · Page 1 of 1 (latest)

devout willow
#

Given that you need the name to get the hash, what advantages does the hash offer vs simply storing the name of the animation in a constant and using the name directly?

rare lagoon
#

Hash comparisons are faster than string comparisons.
I am pretty sure that the animator would convert any string you give it to a hash internally anyway, but that conversion also isn't fast. So, you do the conversion manually once, and then continue to use the hash.

devout willow
#

Faster as in not using GetComponent on every frame or faster as in multiplying by 0.5 instead of dividing by 2?

rare lagoon
#

More like in "not using GetComponent every frame".
But it'll depend on the value of the strings; some strings may be faster that others. But even in that case, you'd probably have to deal with the memory overhead, as hash values are structs (allocated on the stack), while strings are class instances (allocated on the heap). I'm not an expert on that subject though, so take this with a grain of salt.

summer lichen
#

Hash comparison will always be better than string comparison. As zenvin said, hashes are always value-type (most commonly an int, but they can be any other value type like long or Guid)

#

Doing x == 2 is so much faster than x == "somestring", because it has to iterate over every char in the string until it fails to match. and if it's a complete match, it'll iterate the entire string anyway
(of course this doesn't happen if lengths mismatch)

#
"SomeSuperLongStringThatEndsWith1" == "SomeSuperLongStringThatEndsWith2"

This comparison for example (ignoring the fact they are string literals, because compiler will optimise this. assume they are not const literals), will have to search the entirety of both strings, because the point at which they fail to be equal is the very last char, making string comparison an O(n) worst case operation