When parenting a MeshPart (works without a mesh id), to a BasePart, then anywhere else, then back to a BasePart, then anywhere else and so on, for some time, with many MeshParts to make the effect more apparent, then any property changes get seemingly exponentially slower.
In the example place, I’m reparenting 1000 MeshParts between a Part and ReplicatedStorage over the course of a second indefinitely. For this to take place, there don’t have to be that many MeshParts, but with that many, the lag appears quickly, which should make testing easier.
If I reparent the MeshParts between any containers other than BaseParts or don’t reparent the MeshParts at all, then every frame, changing the CFrame takes <0.01 ms
However, if I start reparenting them between a BasePart and some other container, then the amount of time that each property change is shown to take in the microprofiler grows indefinitely and possibly exponentially.
This is the microprofiler after ~10 seconds
And this is it after ~30 seconds
Also note how the frame times change as seen on the top bar.
If you stop reparenting the MeshParts under containers other than BaseParts, and keep them all under the BasePart, the lag stays constant until you continue reparenting them.
Note that in my example, due to how my test is set up, the lag almost doubles when I keep all of the MeshParts under a BasePart. That is because around half of the MeshParts were previously under the BasePart and the other half under ReplicatedStorage, but when I moved them all to be under the BasePart, then effectively there were twice as many under the BasePart.
(Look at the top bar visualizing the frame times)
If you, however, reparent them to a container other than a BasePart and leave them there, then the lag dissipates pretty quickly
In the examples I’ve shown you, I primarily benchmark the lag with PivotTo, which is applied on every MeshPart (red block), as seen in the first image, every frame, regardless of where they’re parented.
However the lag appears with varying magnitude depending on which properties you modify, seemingly correspondingly to their respective complexity/cost in normal behaviour. So doing PivotTo()/.CFrame causes lag quicker than modifying, for example, .Transparency or such. This also happens with workspace:BulkMoveTo(...), when calling it with all the MeshParts and the CFrames instead of modifying each MeshPart’s CFrame individually.
Also note that, as far as my testing has shown at least, this only happens when parenting MeshParts. Parenting other BaseParts around like this doesn’t show any lag, nor does parenting a Model whose only child is a single MeshPart show this.
There are a lot of details and specifics on what exactly needs to be done, so I tried to add comments about everything in the (only) script in the example place, however here are the reproduction steps:
1. Create a Part
2. Get many (about 1000 gives fast results for me) MeshParts
3. Repeatedly parent each MeshPart to the part and then to anywhere else
Make sure not to do so all at once, but rather, like I did, every frame
4. Note: If you're using this test place, make sure to toggle "DoReparent" on under Workspace's attributes once you want the lag to start
This happens on both the client and server, in studio and in the real game.
Make sure to read the comments in the example code, I tried to explain everything in full detail there as well.
bug.rbxl (67.4 KB)
Expected behavior
I expected there to be no performance skydive when I started parenting the MeshParts around between a BasePart and another container.
Side note on why I was doing this
I was adding pooling for a custom particle system which would, instead of destroying particles, move them to ReplicatedStorage for them to be reused later. Depending on how the system I created was used, the particles being pooled could’ve been MeshParts and the objects under which they needed to be parented when in action could’ve been BaseParts. And as I soon found out, when the two conditions (the object being a MeshPart and the parent being a BasePart) were met, lag rapidly took over everything when pooling and instantiating pooled particles began.
