All about optimization

Resources Community Tutorials
, , , ,
#13

Basically for everyone else: Heartbeat runs depending on your frame rate (eg 60 FPS = 60 times a second), while wait() runs in 30 fps.

print(wait()) --> 0.03442870000071707 (there is another number, but its irreelevent)
-- this is how long it took

-- The Average number you will see with wait() and no parenthesis is 0.03
print(1/30)   -->0.03333333333333333 (How long it takes for a single frame in 30 FPS)
-- 33 milliseconds on Average
-- it will not be exact, but its roughly this amount

However, task.wait() exists, which runs the exact same as Heartbeat, but I would assume that it would be better handelled with an event because it takes more resources to run a loop than a event.

3 Likes
#14

task.wait have 2x less time and it’s more accurate, and run service over while loop, it was for wait() not task.wait() because wait have unstable interval, and not everytime it will run every frame

1 Like
#15

Ok this is still confusing, the real answer would be that task.wait() runs at 60hz where as wait() runs at 30hz.

The title says “Run Service over the while loop”. This is misleading because your argument is that you shouldn’t use wait() in a while loop. A more common interpretation would be that a while loop is worse than RunService, this is why it is confusing.

2 Likes
#16

sorry, i’ll explain you:

while loop is less performant to make frame rate operations, it can come in handy when trying to make 8 frames or max 16, but not when you trying to make smooth , run service is more efficent and it has been created for that, + run service can be made every physic simulation, frame ect…

#17

You are wrong.

while task.wait() do

end

and

game:GetService("RunService").Heartbeat:Connect(function()

end)

are the same performance wise

1 Like
#18

but i don’t mean task.wait is laggy
loop is problem, loop need more performance to do, and heartbeat as i know runs every simulation, not every frame, soo if there’s no simulation complete, no function will run

#19

Reply from DF:

It ignores the wait because it is an event, it runs everything the condition for the event to happen it met, in the case of heartbeat, physics have been calculated and so it runs the event, and once another event happens, it’ll run that code separately, unlike a while loop which respects waits,

You need to debounce the event to make it work like a while loop, respecting waits and what not
#20

what about ContentProvider ???
This example is just BindableEvents than trying to explain how you should preload assets here.

Humanoids are not the reason game lags, it’s the DEVELOPER that codes it all and those listed in there are also not the reason to blame.

1 Like
#21

trust me, 100 humanoids lag the game, i tested it myself

#22

The real optimization comes from looking at the micro profiler.

What is good to know is the balance between easy to maintain and readable code versus optimized code.
Deprecated functions aren’t often way slower than newer alternatives

1 Like
#23

The reply from Roblox staff that I quoted says it doesn’t.

I don’t know what a DF is and what that even means.

#24

It’s both. Too many Humanoids are harmful for game performance since it has to manage a lot of different characters at the same time, but the developer’s own coding and implementations also play a huge factor as well

4 Likes
#25

some functions are better to use, for example findPartOnRay vs Workspace:Raycast, or task.wait() vs wait(), or maybe object like body movers - they are good but sometimes they goes badly

#26

Yeah, they are nicer to use, but not necessarily faster. task.wait() is better because it can yeild for 1 frame minimum while wait() only yeilds for 2 frames minimum, can’t yeild for only 1 frame. For FindPartOnRay versus WorldRoot:Raycast, I do not know their performance, but I do know that in the case of the (almost deprecated) GetTouchingParts versus WorldRoot:GetPartsInPart, the newer alternative isn’t really faster

Discussion from Introducing OverlapParams - New Spatial Query API:

WorldRoot uses more optimized collision detection, however, it hasn’t been benchmarked against Region3. So how much faster? idk

For body movers, from what I remember (couldn’t find my sources), BodyMovers run at 240Hz regardless of the Adaptive Timestepping, which will reduce performance if you have a lot of them
The usefulness of the new AlignPosition and AlignOrientation objects can be argued…

1 Like
#27

You can only have the HumanoidRootPart and the Humanoid in the server while the client will handle the rendering part of all bodyparts and animations

Hypothetically speaking, you can have 500 or more humanoids with proper implementation, such as unrendering the bodyparts after the humanoid is 500 studs away from the camera and stopping animations after the humanoid is 250 studs away from the camera

1 Like
#28

Adding performance settings is great, even if roblox already adds that. This can make people be able to play your game at full graphics, for example, in my old pc I was able to play at max settings, but my pc hated the Depth Of Field effect and wasnt able to hit 60FPS, so having a setting to disable it would be good to be able to play it max graphics without compromising the other visuals

1 Like
#29

well, you didn’t read this part anyways

#30

I’m not really sure if this is still true or not, but I heard somewhere on the devforum, a long time ago, that neon was actually one of the fastest materials on roblox. Supposedly, it’s because roblox doesn’t perform specular / defuse calculations on it or something like that, but I don’t really remember.

1 Like
#31

oh, maybe they changed that, it used to be laggy, maybe they fixed that, if yes, take this as outdated point

#32

Thank you for your service! Will for sure use these tips in the future!

2 Likes