An array is indexed numerically. This is a fast approach. Lookups by index occur in O(1) time. A hash is indexed by its keys which are hashed into "buckets" for quick lookup. Lookups occur in O(1) time also, but there is more work going on, so it is a little less computationally efficient. It's a case where Big-O doesn't capture the difference in work being done. This should probably tell you something: Although array index lookups are faster than hash key lookups, the difference isn't usually great enough to care about.

But that doesn't tell the whole story. Let's say you want to find a particular element in an array. You have a choice: If the array is sorted, you can do a binary search which takes O(log N) time. But sorting takes time too, so unless you're maintaining it in sorted order, it doesn't make sense to sort it each time you do a lookup. If it's not in a sorted order, finding a particular element (not a particular index) will take O(n) time.

Finding a particular element in a hash using its key is, in this case much faster. It will always take O(1).

Hashes consume a little more memory than arrays. Generally we don't care about that, because any implementation where a hash is consuming too much memory is probably an implementation where an array could also grow to consume too much. When you find yourself going down that road, you have to look for other solutions that don't attempt to hold the entire datastructure in memory at the same time.

Remember, of course, that hashes do not maintain any notion of order. So if it's your goal to maintain an ordered list, you're looking at an array. Sometimes you can get the best of both worlds by using a hash for its advantages, and maintaining a companion index array to provide order.

This is only the tip of the iceberg on the discussion. You really should check out Mastering Algorithms with Perl. As I said before, it's an excellent source of information on this subject.