I seriously doubt they’re storing a large dictionary that gets updated every time the data model changes. That’s just going to eat up memory for no reason.
If it doesn’t store a dictionary then index cant access it with a hash (which means index would use a loop too)
Optimizing drawcalls is pretty simple, you just reuse meshes more than creating them and also be careful of changing stuff like transparency and color.
Then why wouldn’t they just make it so indexing returns nil instead of erroring? Doesn’t make sense to have two implementations of practically the same thing
Either both use a dictionary or both use a loop. Whether it returns nil or an error doesn’t give insight into the implementation
Also you do know that indexing is O(n) complexity right? There’s no iterating involved
A better way to explain to your average person would be exactly what you said then. Saying optimizing drawcalls would make some people be a bit confused. Regardless, thank you for being better about it than the other guy who just straight up said 'this is all wrong!" and barely even giving a detailed critique.
cool guide, except the performance stuff on meshes is dyzmal and will turn them to shreds (their uv mapping changes too, so textures will become spoofed if you have anything reliant on the map). use “Automatic” which iirc is something in the middle, but optimizes the further they get.
Also, I think this should be in community tutorials.
No, in my test it is not.
Let me clarify my point on this a little better as well, my original post was especially bad lol
Some time in 2022 (i believe), Roblox began to serve all audio files as OGGs (mostly). Uploading either MP3s or OGG files seems to have the file re-encoded. So if your audio files are MP3 and you re-encode them as OGG, your file will be re-encoded AGAIN by roblox and lose a little more quality than necessary.
Plus, if you upload a file as MP3, roblox seems so be able to detect the extra silence at the beginning and chop it off for you (see my other post above). If you use a random converter, there’s no guarantee of this.
So you can keep all your current uploads as they are, but working with OGG sound effects/audio in the future is probably ideal.
Tested this again, FindFirstChild does actually seem to be faster, but only once the instance has enough children
So storing the children in a table with GetChildren is the fastest option. I imagine if you really need the performance this should be possible
Then below 100 children, indexing is fastest. Above 100, FindFirstChild seems to be faster.
Like the roblox page says, store a reference if possible, else, it depends.
of course FindFirstChild is good for error checking, too.
Script used
-- wasn't creating the correct amount of children, and changing to i=1 in the loop wasn't working so here's the hack fix
local iterations = 5000 - 1
local iterations2 = 1000000 / (iterations + 1) / 4
for i=0,iterations do
local part = Instance.new("Part")
part.Parent = folder
part.Name = i
part.Anchored = true
if i % 2000 == 0 then
print(i)
wait()
end
end
print("Children: ",#folder:GetChildren())
print("Iterations: ",iterations2)
wait(0.5)
local t = tick()
for i=0,iterations * iterations2 do
i = i % iterations
local part = folder:FindFirstChild(i)
end
print("FindFirstChild: ",tick()-t)
wait()
local t = tick()
for i=0,iterations * iterations2 do
i = i % iterations
local part = folder[i]
end
print("Instance Indexed: ",tick()-t)
local t = tick()
local folder = folder:GetChildren()
for i=0,iterations * iterations2 do
i = i % iterations
local part = folder[i]
end
print("GetChildren Indexed:",tick()-t)
local t = tick()
for i=0,iterations * iterations2 do
i = i % iterations
local part = i
end
print("Loop Overhead: ",tick()-t)
1 Like
I did a little investigation and determined that it seemingly depends on how you insert the mesh; for example using the toolbox will have the property presumably set to the same value as how it was uploaded (although I can’t really confirm the value when they were uploaded, so I’m just guessing from the results). Inserting a MeshPart directly via the explorer will have the property set to “Automatic”, the documentation also backs this up; which is why I assumed that it was default, I apologise for assuming that it is always the case.
I should have probably clarified on what I meant by this. As far as I know, the served audio files are in OGG format regardless of how they were uploaded. Again, I may be wrong about this and I apologise if I am.