I have an interesting, yet simple question. How laggy is it to get the magnitude of two vector3’s like so: local a = (vec1 - vec2).Magnitude
? If I were to use it in a chunk loader for example, where we were to check the magnitude of a block, and the humanoid root part like so local Distance = (HumanoidRootPartPosition - BlocksPosition).Magnitude
, how “Performance-heavy” would it be to do so? The reason I am asking this question, is because I found a post or a topic a while back (I don’t remember where) that said that it was performance heavy to run magnitude, but I don’t know where, and I would like more info on this.
Since you said “run” magnitude I want to make sure you know that magnitude is a property of a Vector3 and it’s not a function - you’re only performing a math operation on two Vector3s then indexing a property
This is simple to test yourself, but this is not performance intensive at all even when used often in a loop
What I meant is this: local SomeVariable = (SomeVector - SomeVector).Magnitude
Finding a magnitude shouldn’t have much performance impact?
It’s not very performance intensive in its own right, its relatively basic math. If you’re adding in additional operations within that to get those two vectors then it can get a bit more intensive, but its not necessarily something you should be worried about it being slow or lack performance. As Wrathsong said its a property of Vector3, not an entirely separate function call. If you’re really curious how long it takes to run, you can run tests with tick() to get timings on how quickly your code is executing. Simplest answer, not particularly heavy and not something you should be particularly concerned with.
Indexing .magnitude is just as fast as indexing .x
This is because magnitude is computed when the new vector is created: your expression (vec1 - vec2).Magnitude
implicitly creates the vector (vec1 - vec2)
.
Slight digression to address your previous reading: I’m not sure if this was always the case because I had believed that magnitude was computed on first index and then cached, but the tests you will see below show otherwise
Or perhaps you read that square root (which is performed when calculating magnitude) is slow… and I think it is, but it’s not usually very significant on Roblox because we code in lua, and this high level language already slows us so much that calculating square roots won’t bottleneck you
Anyway, here’s the code I used to test:
local trials=1e6
local t=tick()
for i=1,trials do
end
local forbaseline=tick()-t
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
end
local baseline=tick()-t
print('baseline\t',baseline-forbaseline)
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
local x=v.x
end
local coordbase=tick()-t
print('coord\t',coordbase-baseline)
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
local x=v.x
local x=v.x
end
local doublecoordbase=tick()-t
print('double coord\t',doublecoordbase-coordbase)
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
local dist=v.magnitude
end
local magbase=tick()-t
print('mag\t',magbase-baseline)
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
local dist=v.magnitude
local dist=v.magnitude
end
local doublemagbase=tick()-t
print('double mag\t',doublemagbase-magbase)
local t=tick()
for i=1,trials do
local v=Vector3.new(math.random())
local sqdist=v:Dot(v)
end
local dotbase=tick()-t
print('dot\t',dotbase-baseline)
The key takeaways are that ‘coord’ (which calculates how long it took to index key ‘x’) is about as fast as ‘mag’ (which calculates how long it took to index key ‘magnitude’), and the same observations happen for double indexing (you’ll notice that double indexing is faster because they are probably cached very nicely)
You can ignore the ‘dot’ one if you want, I just included it to show that calculating square distance is slower than calculating distance on Roblox with Vector3s
And baseline is just how much time it takes to make a new Vector3 wtih random x coordinate