The slowest bit is the actual sqrt, so I don't think it being an internal command would make a massive difference, as it'll still be performing the sqrt.
Also as Prof said a lot of the time you don't need to sqrt. For example, if you're say checking to see if two objects are within a range of each other, rather than doing the sqrt and comparing against a range value, don't do the sqrt and compare against range value squared.
if dist# > sqrt(xdist#*xdist# + ydist#*ydist# + zdist#*zdist#)
can be replaced with ...
if dist#*dist# > xdist#*xdist# + ydist#*ydist# + zdist#*zdist#
Also if you absolutely need the distance, but you're working within a particular range, you can make a look up table. If your objects are usually going to be within 0 and 10 units of each other, make a 1000 entry look up table with precalculated sqrt() distances of input values from 0^2+0^2+0^2 to 10^2+10^2+10^2.
You can create a function with logic like ...
function FastDistance(x1,x2,y1,y2,z1,z2)
1. Work out distance before sqrt
2. Round/convert to array index value
3. If index value is between 1 and 1000 retrieve precalced value from out CalcedSqrt[] array
4. Else perform sqrt
endfunction
I've done this before in a few games using a lot of sqrts and found the precision was perfectly adequate. You can also do the same for sin/cos/tan etc.
You probably know all this but worth mentioning anyway!
