Below is a screenshot of where a majority for my game’s frame rate drops are coming from. I currently have a few ideas as to where they source of the slowdown is coming from.
Firstly, the bars that are shown to take up the most time are “computeLightingPerform” and “occupancyUpdateChunkPerform” within the “Render” group. What seems to cause these tasks to take up a lot of time involves a function where I’m replicating the swords of players in real time to attach and detach from that player’s right hand when they initiate attacks.
For all players, this involves cloning a reference of the weapon model, positioning it using some CFrame math, then attaching using WeldConstraints. When finished, it’ll delete this model.
For the local player, this transition is made to pretty using TweenService on the part’s transparency. For other players, the transparencies are immediately set instead of being tweened.
I’m not sure if it’s the tweens or the constant creating and destroying of parts that’s causing this to occur. It may be the latter, as I would have assumed that immediately setting transparencies would not cause a slowdown even though they still occur as shown in the microprofiler.
I can’t really find any solid evidence or discussion about whether or not consistently creating and deleting parts causes some sort of slowdown, so that’s why I’m bringing this here.
Just to add: parts are involved in the rendering pipeline by nature. I don’t know much about occupancyUpdateChunkPerform, but computeLightingPerform notions towards the arbitrary fitting lighting needs to do (effects, shadows, so on), so naturally when parts are added/removed from view lighting has to be recomputed to fit the new scenery.
Add this to the fact that you tween the transparency of parts and rendering becomes more expensive, because now the engine needs to account for transparent parts as well. A transparency of 0 or 1 is a hard sell for rendering, but anything between raises the rendering expense. Couple that with consistent creation and destroying per frame and you’ve got a hot mess for performance.
As for the thread RomeoEDD linked, here’s a bit more explanation in that regard: the Gui engine was updated to sport caching behaviour. Guis that aren’t modified don’t need to be re-rendered each frame, so static Guis are pretty relaxed with performance. You can well imagine that a largely dynamic Gui would have the opposite effect. Here’s some reading material in extension to that:
every day is just another day where i realize that a:h is going to get inevitably delayed Thanks for the insightful information. I’ll be taking them into account while I work up a solution.
