Removing support for multithreaded destruction of UObjects

Development Platform & Builds
, ,
1

In CL 33890976 support for multi-threaded UObject destruction was removed from the engine.

This was a feature in previous open-world projects that was essential for avoiding spikes & reducing total time in incremental GC, especially after expanding the coverage to many more UObject classes.

The performance cost of destroying on the game thread in UE5 is showing up on classes with lots of allocations, such as UGeometryCollectionComponents. This Superluminal image shows a typical case taking 2-14ms on PC:

[Image Removed]

I haven’t been able to find an explanation why it was removed. Is it safe for us to restore? Does Epic plan to bring it back in some form?

[Attachment Removed]

2

Although we initially started with a larger subset of classes that fell under the multithreaded destruction, we eventually scaled it down to just UPackage. We kept running into scenarios where someone would add an unsafe operation (not always intentionally) to one of the destructors (and it didn’t even had to be a UObject but a simple struct used by the UObject-derived class) which resulted in hard to track down crashes. Eventually it was concluded that keeping and maintaining a separate path just for UPackage was not worth it and expanding the set of classes was too dangerous and impossible to guarantee safety.

[Attachment Removed]