StreamingEnabled may cause 7500% increase in frame time

I’m running into an issue with streaming preventing its use in my game. This issue has only began to occur within the recent weeks with no issue prior. This does not happen in studio.

In my game, upon leaving a player may remove about 4937 total BaseParts and 1970 other instances.

3827 of these BaseParts are considered Nonatomic and take Replicator: ProcessPackets about 20ms to delete with or without streaming, while the other 1110 of them are considered Persistent and take the client about 3500ms to delete. Some players have reported over 10 seconds of delay while others simply crash.

This has been tested with 3 accounts in a server. The amount of lag appears to increase with the number of players in the server. Without StreamingEnabled, there is no lag.

Game reproduction.

  1. Join this test place on ~3 accounts.
  2. Claim a tycoon by walking to one or waiting ~15 seconds for a prompt.
  3. On the account with a tycoon, leave the game so it regenerates.
  4. On the other account(s), examine the microprofiler spike.

This may also be reproducible by deleting 1k+ persistent parts in an empty place, but I have not tried this.

“Why so many persistent parts?”
My game is a physics-based tycoon which ideally runs ore physics on the client to reduce the massive performance hit it has on the server at even a small number of simulated parts (over 50% lost server efficiency with ~30 simulated parts). Unfortunately, ore physics are ran on the server for the time being by limiting the amount due to another bug which hasn’t been patched yet. I appreciate the work put into this great resource but may begin moving away from its use due to the physics limits it applies.

8 Likes

Same issue, it affects emergency Hamburg and tropical resort tycoon 2, before this bug they used to run 60fps, now they run 25 - 10 fps

2 Likes

Thanks for the report! We’ll follow up when we have an update for you.

When do you believe this issue started occurring?

If you turn off persistence before deleting the parts does the problem go away?

Not sure if this is related, but Streaming seems to also occupy the majority of the server frame time in Glacier Rebirth. Seems to be related to the large amounts of terrain and assemblies.
Roblox Staff can type /e !goto_ea in chat to be teleported to a building far away from the spawn location, in case this would be useful for investigating something like this.

This often causes ping to be very high, as well as people often getting their gameplay paused mid-flight.

I created a simple repro place with 5000 parts in a persistent model and was not able to reproduce this behavior.

Would you be willing to share your repro place with me privately? I’d like to understand what differences might exist. Or if you are able to create a simple repro place that demonstrates the problem that would be very helpful.

Yes, turning off persistence prevents the issue. (Edit: This is not correct) I’ve began receiving reports about a week ago. I will attempt at creating a repro place

I apologize, it appears I was wrong and this issue does happen with streaming modes other than Persistent, such as Nonatomic. I’ve created a repro place which has been able to reliably replicate the issue on my end while in a live server:

streaming bug report.rbxl (52.2 KB)
Place tested in: MWT - Item Testing - Roblox

Streaming enabled:

Streaming disabled:

Are you seeing around 900ms frame time when the problem is occurring? What kind of device are you running on? Can you share your microprofile?

So far we haven’t been able to reproduce the problem using your “MWT - Item Testing” test place. It seems to be around 30ms for the removals, and I see the same duration for streaming vs non-streaming.

This issue is very confusing.

I’ve switched the parts’ streaming mode to Nonatomic to demonstrate its inexclusivity to Persistent, which is what the videos I provided were using. However I too was unable to replicate the issue using the same place I did so earlier, until I switched the “persistent” model back to Persistent that is.

The frame time depends on how many parts are being deleted, but I’ve seen it go as high as 8k ms.

I’ve updated the place to reflect this change and have DM’d you relevant info including a microprofiler dump.

We are still investigating this issue, but I’m curious if you are able to avoid the long frame by doing something like:

peristentModel:Destroy()

instead of

persistentModel:ClearAllChildren()

I have a theory that deleting the children one at a time is what is problematic here. I realize that the first one destroys the model and the second does not, but hopefully you can work around that.

Independent of that recommendation I’ve also made a configuration change that might resolve the issue while we are investigating.

I’ve tried a couple workarounds, both of which reduced the frame time by about 30% but did not remove it entirely.

Workaround 1 used Destroy as you suggested. Workaround 2 parented the model to nil, ran ClearAllChildren, then reparented the model to workspace.

I’ve updated the place to include these workarounds if useful, however since the mentioned configuration change I haven’t encountered the issue.

streaming bug report v2.rbxl (53.5 KB)

1 Like

This was resolved due to the configuration change.

Thanks for bringing this to our attention and for providing the repro place.

1 Like

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