How to amortize the performance cost of garbage collection and level streaming?

Are there any recommended methods for amortizing the costs of garbage collection and visibility changes? Can we control the number of actors per frame that are destroyed or have visibility changes applied?

Details:

We are seeing major performance spikes related to level streaming. We are currently using LevelStreamingVolumes but would expect to see similar results using WorldComposition.

The largest spike occurs when the garbage collector cleans up an unloaded level. This spike persists over several frames. Additionally, we see single frame spikes when a level’s visibility changes (as all actors in the the level change visibility in a single frame).

56478-visibilityoffthenunload.png

The above image shows the performance hit of asynchronously loading the level, followed by the level becoming visible.

The second image shows the previous level losing visibility (via LevelStreamingVolume), followed by the prolonged spike of garbage collecting the unloaded level.

I’m seeing similar issues with unloading streaming levels; did you make an progress on this?

Hi Philippe,

Unfortunately, this remains an open, but low-priority, issue for us. We have not found a way to change the Garbage Collector’s behavior with respect to the number of objects cleaned per frame or the total time spent in GC per frame.

However, the Trello roadmap lists “Garbage Collection performance optimizations” as underway for November, so we’re hoping to see some marked improvement in 4.11 or 4.12.

Thanks for the update!

Three years later and we still see the same heavy spikes on level load and unload. Was there ever anything done on the GC regarding these issues? If so, is there some documentation or at least code you can refer to, so we can learn how to mitigate the issues?

another year and the same problem …

I still have same issue.