Well, the key to getting the best speed out of a hash table is to make sure it's size is relative to the amount of data you're going to store in it. If you made a hashtable of size 1, it's really just a list, and just as slow.
If you know you're going to need to store say 50 elements, and you make you're hash table 150 elements big, you'll have very few collisions (if any), and so it'll basically be just as fast as an array lookup (the hash algorithm I'm using - borrowed from some brilliant comp-scientists - is extremely fast and very good at distributing hash results evenly). It'll only be marginally slower than an array lookup because it has to hash the key - but I've tested it and gotten 1 million plus lookups + insertions in about .3 seconds. The speed will vary a bit based on the # of collisions you have, but unless you have like 5000 objects in a 50 element hashtable, the speed hit will be extremely minimal.
The array lookup method would still be faster on small arrays - but having to scan even a 50 element array 50 times (once per each element in the array) could - worst case scenario - result in 2500 iterations, and that's probably going to be slower. If you were looking at a 50,000 element array, or, if the array was an array of pixels (a bmp), you might have millions of elements, obviously the hashtable would be exponentially faster.
I'm not saying that my implementation of the challenge is necessarily better than CS_TBL's friends - it's just that it'll be faster on large arrays and is flexible enough to handle arrays of any size and (in the condensed version at least) all you have to do is change the parameter type of AnalyzeArray() and it can handle doubles, floats, strings, objects (that you have written a compare method for or have one built in), basically anything at all.
If you know you're going to need to store say 50 elements, and you make you're hash table 150 elements big, you'll have very few collisions (if any), and so it'll basically be just as fast as an array lookup (the hash algorithm I'm using - borrowed from some brilliant comp-scientists - is extremely fast and very good at distributing hash results evenly). It'll only be marginally slower than an array lookup because it has to hash the key - but I've tested it and gotten 1 million plus lookups + insertions in about .3 seconds. The speed will vary a bit based on the # of collisions you have, but unless you have like 5000 objects in a 50 element hashtable, the speed hit will be extremely minimal.
The array lookup method would still be faster on small arrays - but having to scan even a 50 element array 50 times (once per each element in the array) could - worst case scenario - result in 2500 iterations, and that's probably going to be slower. If you were looking at a 50,000 element array, or, if the array was an array of pixels (a bmp), you might have millions of elements, obviously the hashtable would be exponentially faster.
I'm not saying that my implementation of the challenge is necessarily better than CS_TBL's friends - it's just that it'll be faster on large arrays and is flexible enough to handle arrays of any size and (in the condensed version at least) all you have to do is change the parameter type of AnalyzeArray() and it can handle doubles, floats, strings, objects (that you have written a compare method for or have one built in), basically anything at all.