I’ve always avoided this because I didn’t want objects being sent over the network until they were ready.
This is usually because I want to set the name before putting it in the game. (ChildAdded events). Glad to know that’s paying off!
10 Likes
All I know is that setting .Size of a part is one of the most expensive property changes I’ve ever seen in my life, and it’s because of these collision checks. Changing a part’s size on Heartbeat is not a good idea right now.
I cannot wait til we are able to remove collisions off of a part.
3 Likes
It’s not quite precise. Changing properties of things parented to game requires additional work (sometimes, a bit; sometimes, a lot). Setting parent first pretty much guarantees that you’re doing a bunch of these redundantly, that can result in performance that ranges from slightly worse than usual to catastrophically worse than usual.
1 Like
So wouldn’t that mean that just setting the parent directly after creating the object has the same (negative) effect? I think that based on the title, a lot of people are confused and think that calling Instance.new(“Name”, parent) causes performance issues by itself.
Yep, same problem.
If you read his whole post, it’s pretty clear, but I can imagine a lot of people not reading it completely.
Maybe a “TL;DR Only set the Parent property at the very end” would indeed be a good idea.
@zeuxcg
(added this mention by editing the post, not sure this even pings the person)
1 Like
If we’re about to make a lot of changes to an object, would it be a good idea to set its parent to nil, make all the changes, and then re-parent it?
1 Like
Spam reparenting objects causes the explorer to consume a ton of memory, so be careful.
There’s an explorer running silently in the actual game? What the Hell.
1 Like
I doubt it, but for studio…
Oh then that doesn’t matter. Players don’t play the game in studio lol.
there’s pretty much two reasonable ways of getting around the Size lag right now
Parent = nilCFrame = ridiculousValue
Parent = nil is (marginally) faster in live games, but use it with caution (especially if your game listens to hierarchy changes). Never use it in plugins–it causes unnecessary explorer updates and makes selections flash.
-- Use in live games (100 passes: 0.0054426s)
part.Parent, part.Size, part.Parent = part.Parent, newSize, nil
-- Use in plugins (100 passes: 0.0065138s)
part.CFrame, part.Size, part.CFrame = part.CFrame, newSize, largeval
--where local largeval = CFrame.new(3.4e38, 3.4e38, 3.4e38)
If in doubt, use the second way. There’s not much performance difference and it’s less likely to cause weird side effects.
Nah, only makes sense to do it for size.
7 Likes
Phew… Lucky I only really use the first option, Couldn’t be bothered to learn the other ways to create a new instance.
2 Likes
I thought this was common knowledge? 
Yes, it’s the same, but I rarely see code that manually assigns Parent as the first thing. The problem with Instance.new w/parent argument is it’s first class - easily available and asking to be used.
It depends on what the properties are. In general unparenting and reparenting are very costly, but in some rare cases the sequence of property updates you’re doing can cause even more costly updates. I would say that the general rule in this case is “don’t unparent/reparent” but feel free to test performance in cases that are important for you because sometimes you will get a benefit.
3 Likes
Huh, Good to know.
I was aware that changing the size of an object for sure cause a lot of lag (have you ever tried doing it every frame?) but I was unaware that there was a way around it. Thanks for the heads up!
2 Likes
Or Ctrl+H if that’s faster. ^-^
1 Like
This would have been really helpful when I was starting my new game.
Well back to recoding everything.
2 Likes