A common misconception that proliferated mainly during Resonite's early days is that the amount of slots that an object contains is directly related to how performant the object is. This is not usually the case. It is also stated that slot count has no impact on performance at all. This is also not usually the case, and the reality is slightly more complicated than both extremes.
In general, at a baseline level, the amount of slots on an object does not affect its performance within the world. A world that contains a high-slot count item will, in general, not perform any worse than a world without said high slot count item when considered in a vacuum.
The real slowdown of slot count starts when functions need to iterate over all the slots and potentially components of an item while also performing some action. This requires multiple hits of heap memory and isn't very cache friendly. The effects of these kinds of actions can usually start to be felt after a slot count of 10000-100000+ depending on the amount of components on each slot and the action that is being performed. This includes, but is not limited to:
- Duplicating or destroying slots.
- Computing the bounding box of a slot. This is used in gizmo rendering of the slot, for example.
- The Body Node Slot node, especially if it can not find the body node or the body node is "low" in the slot hierarchy it searches over. This can become especially bad with ContinuouslyChanging in a flux group.
- Selecting items with the Dev Tool. This iterates over only slots—not components—of the entire world root, and as such its effect is much less pronounced than the other items in this list.
Element count
Another slowdown that slots contribute to—but are not always the main cause of—are iterations over all the elements of an item. This includes, but is not limited to:
- Initial synchronization of a world. The more slots, components, whatever elements there are in a world, the longer it will take to synchronize the world state.
- Initial spawning and loading of an item.
Other causes of slowdowns
Some hitches or slowdowns that may be mistaken for slot count but are usually caused by other factors include:
- ProtoFlux compilation on item spawn. If an object contains a ton of ProtoFlux, it will take time to compile it on spawn. While conventionally, ProtoFlux is done on a one-node-per-slot basis, the slowdown mainly comes from the components rather than the slots.
- Avatar hitching on load. This is usually caused by a large amount of blendshapes on a high-poly mesh, as the game has to recompute the mesh for every blendshape on load. This may also be caused by RAM/VRAM paging during allocation.
- General avatar lag. This could be due to many factors, but it's rarely from slot count alone. If blendshapes on a high-poly mesh are being changed frequently, the aforementioned recomputation of the entire mesh will be done, causing lag. If there is generally a large amount of bones and vertices, IK can cause lag from computing the mass amount of slot transforms and mesh deformations.
- Slow raycasts. This is caused by a large amount of heavy colliders in a world, mainly convex hull colliders and mesh colliders. It is generally advised to optimize the colliders in a world as much as possible.
See also
- Optimization guidelines for more in-depth guidelines about optimization in general.