Rojo crashes or freezes when syncing large projects (10,000+ instances)

[Froredion]

Description

When syncing large projects (around 10,000+ instances), Rojo often crashes or locks up both on the Rojo server and inside Roblox Studio.

The issue seems to occur when both the server and Studio are actively synced, especially when many instances are suddenly added or updated at once.

Interestingly, the initial project load (startup sync) is smooth and stable — the crashes typically happen during live sync after initialization.

Steps to Reproduce

1. Sync the project. Keep both Rojo server and Roblox Studio synced.
2. Add an .rbxm file with huge amount of instances like a build or a map containing this amount: (~10,000+ instances).
3. Observe Rojo locking up or crashing. Edge case, happens only sometimes.

Expected Behavior

Rojo should handle large live sync updates smoothly without crashing or freezing.

Actual Behavior

Rojo crashes or becomes unresponsive when a large number of instances are added or updated during live sync.

Question

What’s the recommended way to handle large project syncing (10,000+ instances) smoothly — both server-side and Studio-side? Would chunked syncing, throttling, or deferred writes be a feasible approach to improve stability?

I’m asking this because I’d like to explore ways to smoothen the user experience for instances like this.

[Dekkonot]

I'm able to load rbxm files with 10,0000 folders and 10,000 parts into the server with minimal issues, even after triggering a bunch of changes from them. Do you have a file that reproduces the server hanging? I admittedly have a quite good computer, so it's also possible I'm just dodging the problem.

In terms of the plugin hanging, this is partly Roblox's fault and partly ours. Roblox in general does not like it when you create a bunch of Instances at once, especially Part Instances. If you're putting a complex model into Workspace, it's triggering physics recalculations and rendering stuff that might cause a small hang even under ideal situations.

However, we are not helping the issue! We currently try to create and parent everything in one frame, which is not great for large patches like the ones you're describing. There's a few obvious ways to fix this, ranging from proper fixes (make applying patches take multiple frames when it has to) to patchworks (make everything else more efficient so the only thing bottlenecking us is Roblox), but that work hasn't been done yet. I'll try to prioritize it soon, but no promises.

In terms of handling this right now, probably your best bet is to not do that. What's your workflow look like that's got a 10,000 Instance model reserializing frequently? Is it possible for you to just not sync them and instead just have a workflow involving rojo build and then opening it in Studio?

[Froredion]

Hey! Thanks for the detailed explanation, that makes sense. Yeah, the issue seems to happen specifically when syncing newly created large folders while the Rojo server and Studio are both running. Even if the total instance count is fine, when Studio receives a burst of thousands of new Instances at once (especially parts or models under Workspace), it tends to hang or even crash. (Only Rojo Server, I have a great PC too)

From my quick benchmarking, it looks like your instance loading approach behaves almost the same as Roblox’s native .rbxm loading, both have nearly identical runtime performance when handling 10,000+ instances. Just wanna do some tweak and experiment what could possibly make it more optimized haha

[Dekkonot]

A part of it is also potentially the patch visualizer. I believe we calculate the state for it even when we aren't rendering the UI, and that's potentially expensive. Would have to check though.

I imagine @boatbomber would have more to say about performance of the plugin than me though. He's spent a lot more time working on it.

[boatbomber]

Yeah, it does run that computation when a patch comes in: https://github.com/rojo-rbx/rojo/blob/master/plugin%2Fsrc%2FApp%2Finit.lua#L601

I'll do some benchmarking this weekend and see what I can squeeze out.

I suspect that the patch tree build is not that big a deal, but yeah it does compute for every patch. It kinda has to though since it needs to happen before the patch applies in order to capture the proper before and after and states.

[boatbomber]

I'm seeing HttpService:JSONDecode taking 15-30 seconds and hanging Studio while decoding the body of the response from the server (it's 365,689,769 bytes in my test scenario based on a real world project).

[Froredion]

Doesn't seem bad, it has edge case to disconnect 10% of the time which would be hard to repro lol.