French to English translation:
"The little stuff can add up."
I have to disagree. While optimizing this distance function might save you 5fps, optimizing the ALGORITHM will save you 10, and the optimization of the distance function then, since it will only be called 20 times instead of 20,000, will only give you a 0.005 fps increase on top of that.
And while every little bit counts, you have to consider if it's worthwhile to even bother with.
Of course I encourage anyone to use the SQUARED distance when possible, because that requires no extra effort. But you can't always use these weird alternative distance functions and get away with it. And anyhow, my point was that you should optimize the algorithm FIRST, not that you should not attempt to optimize the distance function.
What I suggest is that if something is too slow, you examine the algorithm first, and see if you can divide the problem up into a set of smaller problems... gorup objects together for example, and then only work on those within a certain region. And THEN, once you're sure you've got a good algorithm, you can go for the smaller optimizations. But I can't recall a time when I have really needed to optimize a distance function in my code. I use the squared distance when I can out of habit, but I don't think I've had any situations where it actually provided a significant benefit.
Btw, that's another trick you should be aware of. If you are merely COMPARING two distances then you can just delete the square root, and compare the two results, and you will get perfeclty accurate results with very little cost.
"The little stuff can add up."
I have to disagree. While optimizing this distance function might save you 5fps, optimizing the ALGORITHM will save you 10, and the optimization of the distance function then, since it will only be called 20 times instead of 20,000, will only give you a 0.005 fps increase on top of that.
And while every little bit counts, you have to consider if it's worthwhile to even bother with.
Of course I encourage anyone to use the SQUARED distance when possible, because that requires no extra effort. But you can't always use these weird alternative distance functions and get away with it. And anyhow, my point was that you should optimize the algorithm FIRST, not that you should not attempt to optimize the distance function.
What I suggest is that if something is too slow, you examine the algorithm first, and see if you can divide the problem up into a set of smaller problems... gorup objects together for example, and then only work on those within a certain region. And THEN, once you're sure you've got a good algorithm, you can go for the smaller optimizations. But I can't recall a time when I have really needed to optimize a distance function in my code. I use the squared distance when I can out of habit, but I don't think I've had any situations where it actually provided a significant benefit.
Btw, that's another trick you should be aware of. If you are merely COMPARING two distances then you can just delete the square root, and compare the two results, and you will get perfeclty accurate results with very little cost.