Parenting many objects to a PersistentPerPlayer model takes an obscene amount of time

There seems to be an issue where parenting objects to a PersistentPerPlayer model takes an absurd amount of time. For reference I’m reparenting ~1500 descendants. At no point does Roblox ever stop responding.

This issue does not occur when the modelStreamingMode is Persistent.

This is the case both when setting the modelStreamingMode before and after parenting the objects (so both create model → make persistent → parent objects and create model → parent objects → make persistent makes the issue occur).

Typical startup (~20 seconds, not ideal but not unbearable- you can tell startup is done because of the ellipses being added):

Startup except I’m trying to set the modelStreamingMode to PersistentPerPlayer (I gave up after 10 minutes), at no point does Roblox stop responding:

Specs:
AMD Ryzen 7 7800X3D @ 4.20GHz
NVIDIA GeForce RTX 4080
32.0GB DDR5 RAM @ 5200MHz

Logs, repro file are in private content area

A private message is associated with this bug report

1 Like

Thanks for bringing this issue to our attention. We are investigating.

1 Like

We have created a fix for this issue and hope to enable it in the coming weeks.

Having said that, you still may not see as good performance as you would like even after this fix. You are creating a large Atomic/PersistentPerPlayer model in your repro situation. Large both in number of instances as well as spatial extents. The reason why the issue does not occur when your model is set to persistent is because we don’t care about the spatial extents for persistent models, it is persistent for all clients no matter what spatial structure it has.

On the other hand PersistentPerPlayer models may be streamed to clients even if the model isn’t persistent for that player due to the spatial extents of the model. We must keep these extents updated as the sub components of the model change. For this reason Atomic/PersistentPerPlayer models with large numbers of descendants can be costly to update.

If possible I recommend breaking up your single large model into smaller models if possible, using Atomic/Persistent/PersistentPerPlayer where appropriate.

Thanks for that.

We were planning on making it so the terrain in the rbxl would be a toggle and we would add persistent players based on whether or not they have the toggle enabled. Would breaking it up into smaller models and adding persistent players for every model still give the performance gain?

My performance improvement is for the situation where you have large numbers of descendant parts in an atomic model. If you break things up into smaller models you should already have good performance without waiting for my fix.

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.