GC extremely huge hitches in empty map


from the documentation: “Garbage collection in Unreal Engine 4 is fast and efficient, and has a number of built-in features designed to minimize overhead, such as multithreaded reachability analysis to identify orphaned Objects, and unhashing code optimized to remove Actors from containers as quickly as possible.”

With a completely empty map, set “time between purging pending kill objects” to 1 second to clarify the hitches:

What’s going on here?

Edit: It also happens in a new UE4.25 project only with starter content:




For me, The itches seem to be due to tessellation on the landscape.

Glad you spotted they have to do with garbage collection Though.
something must be wrong with how the landscape is removing tiles?

The map is completely empty. There is nothing in it. No actors, no landscape. In a new UE4.25 project there are also spikes, but not so big ones (second image).

Type in stat raw, gives you per frame resolution. I cant reproduce this in default map, tested from 4.17 up to 25. Time set to 1.0 is not ideal anyways, it will always give you a spike but nothing like this on the default map. Check if you have custom settings for GC and revert to defaults, also disable marketplace plugins. Update drivers. Does your equipment meet the hw requirements of ue?

stat raw:


No custom GC settings except for “Time between purging…”:


No marketplace plugins, up-to-date drivers.
I have a AMD FX 8350 and GTX 970. So I meet the HW requirements.

The spikes are a bit smaller if I uncheck “Allow Parallel GC”. Does that give a hint?


But they are still in an empty map in a somewhat bigger project at 250 ms…

So the map has absolutely nothing in it?
what id you add something to it? A mesh. Out of view so it’s purpously culled.
the reason being that just maybe having “nothing” in the level is not expected. There should really be no situation in which a level is completely empty?

This changes nothing. Still spikes.

Yes, dont use empty map, and run perf tests in standalone / cooked game instean (and not just play in editor).

Just make sure all motherboard etc drivers are also up to date, sometimes driver obtained from manufacturer websites gives better stability and overall perfomance. Not much else to go on,

In standalone it’s the same, but in a cooked game the spikes are even smaller. But how can it be that adding more assets to the game does make the GC slower? Why does the GC check if references are invalid which never can become invalid?
I doubt that with those spikes it is possible for me to make a playable VR sports game. What do you think will the player do if he is just about to beat a level, then the game pauses for one second, he loses the focus and loses the level… I would throw the game in the corner and never touch it again. Maybe the best option is to turn the GC completely off and manage the memory by myself or take all actors and UObjects from object pools and never destroy them.

This may be an issue with your machine.

I do not have these exact spikes.
the steps to reproduce being so simple as “open an empty level and stat” you could literally just poll who else here may have the same issues.

It could also be due to your install, so go into the launcer and verify files.

Next, conflicting sofware? Don’t ask me how it can interfere with GC. I haven’t a clue…
but, if something like a miner is running and hogging GPU/CPU at intervals that could potentially explain the spikes?

There are plenty of issues with VR, they run apps in the background causing cpu/gpu work, that are indeed can show up in the graph. For instance oculus will run another unreal process for the home. Maybe you want to unplug vr and disable all related services (eg exit steam, disable oculus service, etc) also make sure no other 3d apps (nor miners in the background) run, so it gives you best circumstances for testing. Unreal by default comes with VR plugins enabled, they will fire up / restart these shutdown background services so you should turn them off at the plugins and run the tests.

Once you managed to get rid of the source of issue, you can start reenabling things one by one to see if and when the problem coming back.

It does not. However, Editor itself can make things look pretty bad, as well as bp content (eg stuff in constructors) and other code stuff too. Hence it’s much better to run standalone/cooked for performance evaluations.

He may not going to suffer the same issues. Also, you just found that cooked games runs “better”. Out of curiosity how much better actually?

[USER=“3140864”]MostHost LA[/USER] OP has specified he is forcing GC in 1sec interval (gc.TimeBetweenPurgingPendingKillObjects 1.0), that’s the source of spkies, but their amount is in question.

It is not ideal to run gc on 1 sec, by default it is set on 1 min intervals. This also means there is like a 1% chance the player will get a hitch, if any at all. With 1sec intervals you just over emphasized this by 60 times already, and this is quite misleading.