I agree though, if you never have more than 100 records(ish), no complex solution will ever beat the simple one, because of the rather large constants involved in setting it up. JavaScript is (thankfully) rarely a langauge for large dataset processing anyway :)

And yes, I completely agree with the main point: the “good enough” solution takes maybe 20% of the time of the “best”, so it’s vastly better overall.

And yes, a break; (or even just a return) would be appropriate :)

P.S. You know, I never apply big O. I don’t know why. Obviously, I need to retrain myself. :)

P.P.S. I just realized that I don’t break the loop when I find the element in the “complex” result, meaning every single lookup is O(n) instead of averaging like O(n/2). Derp.

1. You use an iteration function that always itself iterates over the entire dataset, turning your complex solution into O(n^2), while the simple one is using the built-in hash lookup of the javascript engine, which is between O(1) and O(n) on average, depending on the hash details and implementation of the js engine.
2. You never exploit the fact that the numeric ID is (I presume?) unique. You could use this to build a index table, so you have id(n) == index[n] and val(n) == value[n].
3. If you had this kind of table, you have multiple options, the most obvious being a binary table search for the ID (inline instead of recursive for a constant-time speed bonus). Buckets+linear or buckets+binary would also be viable options.
4. If the complex solution wasn’t O(n^2) it would still be unlikely that it would win for datasets this small. Even a very well-tuned implementation will probably need around 100 elements before we can see any real effect of the choice of algorithm.

On a related, but not identical note, here’s the jsPerf results of iterating over sparse arrays

http://jsperf.com/iterate-sparse

Now, this is just getting to the elements at all, without even searching for them, so this is only half the puzzle. But you can see quite clearly that in this case, the simplest solution also wins (for key in array), while competing solutions are only marginally slower though. I have an (unprooven) feeling that some of these sparse-array implementations would lend themselves well to fast searching, too.

“Fun” fact: I went through something similar when implementing Python dictionaries in Pyjaco. Keys can be any hashable object (pretty much any python object at all), so JavaScript can’t even store the key, unless I do something like this, using the object as the ID. Now, I ended up using a (key, value) array-of-arrays, and just searching through it linearly when looking for a value!

It wont scale up to many elements, but for the rather small datasets I’ve worked with for now, it’s actually the fastest solution (and by far, the simplest). Lesson? Don’t ever prematurely optimize. So yes, I do agree with your point, even if I don’t entirely agree with your findings :-)

—Alex