They aren't - at least not generally speaking.
Depends on what you're trying to access by. If you need to index by anything other than an int, they're much faster since you don't have to search every single element to find the right one.
A Hashmap requires an ammount of memory greater than twice the ammount of total objects you want to store, and this ammount must be a prime number, to avoid hash collisions
Huh?
Hash collisions aren't a big deal in any decently-written hash map (and I'd argue that one that DOESN'T deal with that is written by a complete amateur). The hashed value of the key just specified which bucket to look int... buckets can then be pretty much whatever data structure you want, though lists of some type are probably most common.
Wave:
1. How can TMaps be faster than TLists or Arrays?
They're faster if you need to index by something other than an int. They can be more memory efficient than a straight array if you're populating a sparse array.
A good example: If you have an image manager that keeps track of images are loaded, you may need to grab an image by file name. A Map of some sort (be it hash or tree or whatever) is the best data structure to use in this case for anything more than ultra-trivial cases, as it does not require that you go through the whole collection of items one at a time, doing a string comp on each one.
I also think you're getting hung up on the word 'hash'. All a 'hash' is, is a hash function. That's just a function that takes in some data, and spits out a number. Good hash functions have some things that they do to minimize collisions and increase the distribution of the results, but that's all a hash function really is.
You could 'hash' a string by adding all of its ascii codes together. That wouldn't be a very good hash function, but it'd be a hash function.