If sadmanface hadn't worried about speed, he wouldn't have asked that question, I assume.
You must be new here. (j/k)
Seriously, just look for all the conversations we've had on PM about "premature optimisation" (or, for the 'mericans, "premature optimization"). As in, one of the roots of all evil. It's actually fairly common for new monks to ask about speeding things up as if they had to optimise every single cycle, and then to focus in on an area of no importance. For example, we don't know if sadmanface's program runs on a heavily-loaded web server dealing with data from mySQL that is likely in a cache and thus pre-loaded into memory, or if it's reading its data from a series of files across NFS and/or samba where even at 10,000,000 items, the I/O would so completely overwhelm the timing as to make any other modification completely moot (chopping seconds, ENTIRE WHOLE SECONDS, off a 95-minute execution).
So, you're right, we don't know sadmanface's predicament. But experience shows that assuming that someone who is worried about speed is actually correct to worry about it is a mighty optimistic assumption. This is not an intelligence test here - it's an experience one. Before I joined PM, I probably would have asked similar questions about micro-optimisation. Having been exposed to the Wirebrush of Enlightenment on this issue, though, I now try to focus on bigger picture items, and only worry about small items when it becomes apparent that the small item in question is being magnified by being called too often (where I usually just go for caching instead, though probably not in this type of case), such as in a tight loop. I don't think my intelligence has grown over that time (heck, I have a kid now, so, if anything, it has dropped), but my experience has.
As to an algorithm that scales bad in the general case: again, if you're never going to need to scale, the time you spend on developing the advanced algorithm is wasted. If you can save yourself a half-day by developing the slow, poorly-scaled algorithm which you can then use to implement some other feature your user(s) actually cares about, you'll be far ahead. And that may also be something that sadfaceman has overlooked.
Now, all that said, sadfaceman may actually have thought about all these issues and done the due diligence to prove (or at least provide sufficiently strong evidence toward) this as his bottleneck. In which case, he has received ample helpful advice. My experience on PM doesn't preclude this possibility, but the statistics aren't in favour of this possibility.
In reply to Re^5: find closest element of array without going over
by Tanktalus
in thread find closest element of array without going over
by sadfaceman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |