Back when I first started programming, the rule was “avoid sqrt at all costs” to the point where C code would often implement ‘close approximations’, either with lookup tables or like Quake did with an equation that approximated the curve ‘enough’. I mean, back then a CPU could take something like 250+ cycles to calculate sqrt. Division was also really bad and on the “avoid if possible” list.
On modern CPUs, these operations are still expensive but not anything like what they were. In fact, sqrt is very close to division in performance now… both of which are like 13-14x slower than add or multiply. But keep in mind that on average at the CPU level an add or mult is 1 cycle. So it’s not that bad.
I would say the modern guidance on both sqrt and division would be “avoid if possible”. And consider it in your algorithms.
So, yes, if all you are doing is comparing the distance of objects to some fixed constant then 100% definitely do what @1000ml suggests. It basically costs you nothing to do it and turns it into all mutiplies.
Also, if you have some algorithm that requires you to do distance checks between all objects in the scene then it is better to organize the data spatially such that you can avoid large swaths of comparisons. (That’s more or less true, sqrt or not.)
But in modern CPU architecture, sqrt is not as poison as it used to be. So don’t go to extreme measures to avoid it… but if the sqrt isn’t really necessary anyway, then don’t do it. (Same with division… in an inner loop: better to multiply by a precalculated 1/value than to divide by value)