I’m not sure how many people are aware of this, but resizing baseparts is a very very expensive operation. In theory, setting a part’s Size should be no different to setting a part’s Position or CFrame, but unfortunately it is. In fact, it is one or more orders of magnitude more expensive than something like a CFrame set.
Does anyone know of any decent workarounds to this? I’ve been using SpecialMeshes quite heavily recently because SpecialMeshes can be resized using the Scale property (that is, the visuals of a mesh can be resized; that is all I want anyways, not the collision information). However, Roblox is increasingly abandoning SpecialMeshes and in some cases SpecialMeshes straight up cannot be used, like for resizing an r15/rthro rig.
You can use a mesh part and turn off collisions. Are you actually running into lag from resizing parts? Did you just check the time it took for the operation to complete and measured something like a thousandth of a second instead of a millionth? Is it client rendering or server lag? It does not matter how long an operation takes so long as everything is done before the next frame. Some things are just not optimized.
I meant the cost of the size operation should be similar if not identical to the cost of a cframe operation. In 3D graphics, a mesh’s orientation, position and size can all be defined by one 4x4 matrix called the transform. In theory, setting the Size should be modifying the same transform matrix that setting the CFrame modifies. However, the Size property does additional calculations, likely relating to the physics tree or something along those lines, which makes it substantially more expensive.
That’s what the search function does then. However, if you want some actual feedback, show us the code you are using as well as some metrics on how it fares vs similar operations.
Personally, I have never resized so many parts that it has become a problem.
Can you please provide us your script that’s having the issue, from there, we can help you reduce the issue and essentially solve it. We don’t understand your issue.
Edit: even a scenario will help us better understand the situation.
I assume this has something to do with recalculating the hitbox, as a result of this there isn’t a whole lot you can do. If its a set list of sizes you are setting blocks or meshes too, you could in theory have a list of the instances of the desired sizes stored in ReplicatedStorage and reparent them whenever you need them.
This has been an issue for god knows how long, hopefully they will do something about it soon.
I believe parenting stuff in and out of workspace has similar cost to a size operation (have not tested this, but just in theory).
It is extremely unfortunate that Roblox neglects the use cases of their engine which do not involve any physics whatsoever. It would be so incredibly easy for them to give us specialized tools that completely bypass all physics calculations for major performance savings. I assume the cost associated with Size operations also stems from the physics engine.