I have a somehwat important problem, as in my game, there are quite a lot of projectiles (for a mobile game at least) and after some time (like 30-40 seconds ca.) there is a huge lag. When tracking with the STAT XXXXX commands the GC Mark Time seems to be responsible for this, it suddenly takes a huge amount of time, then goes back to 0. Will this be like this in released, final state as well? What can I do to fix this? Did I do something wrong with destroying my projectiles? (Actually they get destroyed by the end of their lifespan, so that shouldn’t be it, right? And in the other cases I simply use Destroy() …)
I’d be glad about any ideas
PS: My editor keeps stacking up "Deleted Actor"s in the actor list on the top right corner as well and that number just gets bigger and bigger when I shoot but barely decrements…
PS2: This issue happens on PC and on Android, in the Editor and when launched to the phone
EDIT: I checked with the profiler, it is indeed the GC Mark Time, taking a maximum of 1200ms at once!
Hi Nanoxin, you are probably right that it’s the GC running, and this is somewhat normal in Development build. To verify your performance, there is a command line that is helpful that should remove that lag : -NoVerifyGC
From the documentation:
-NoVerifyGC Otherwise expect massive hitching in Release builds at least every 30 seconds or so.
This should not be present in Shipping build.
Here is the link to the documentation :
Hope this helps!
Thanks, wasn’t sure about this. Is there any reason NOT to use that command? Or: What do I miss when turning it off? Why is it on by default?
You can also, try adding:
In your DefaultEngine.ini file. These numbers are rather random but you can get the correct values from you cooked game log output, just look for something like this:
[2015.03.04-10.00.21:716][ 0]LogObj: 38723 objects as part of root set at end of initial load.
[2015.03.04-10.00.21:716][ 0]LogUObjectAllocator: 9779464 out of 0 bytes used by permanent object pool.
And put whatever the first number is (38723 in this case) in MaxObjectsNotConsideredByGC and the second one (9779464) in SizeOfPermanentObjectPool.
This will help reduce the number of objects GC has to go through when checking for objects to collect.
Also, consider using pool of pre-allocated objects for objects you spawn often. It should work well for projectiles which would get added to world from pool, and return to pool after they’ve been destroyed.
Thanks for the idea,
however, I haven’t used anything like that object pool yet, is there any engine feature for that? Or would I just have to initialize (spawn?) let’s say 100 projectiles at the start of the game and then instead of spawning them on fire, I’d take them from the Pool and place them in the world and instead of destroying put them back into the “pool”?
Would that be your suggested workflow or did I misinterpret something here?
Thanks for your help!
I believe it already does that for you. Here’s a link to a question I posed some time ago: https://answers.unrealengine.com/questions/125888/should-i-create-a-pool-manager.html
as a follow up question, is there a reason the engine couldn’t just read the number and set that as MaxObjectsNotConsideredByGC/SizeOfPermanentObjectPool on it’s own during load? it’s cumbersome when number of objects in root set changes frequently
Hey guys, sorry to revive an old thread, but I’m having this same issue: the game has a lot of hitches due to the Garbage Collector. I’ve tried both the suggestions (-NoVerifyGC when launching the shipping build and setting MaxObjectsNotConsideredByGC and SizeOfPermanentObjectPool in DefaultEngine.ini), but I’m still experiencing hiccups.
I’m not creating/destroying a lot of objects at runtime, nor do I have a lot of objects/entities; this even happens in semi-empty levels with just the player and a couple of AIs.
I could live with it (for now), but I have to showcase a demo of our game in a few days and I could really use some help to fix this, or at least reduce the problem somehow.
The major problem is that when the hiccups happen, the game freezes for a very short time period (less than 1 second), and when it comes back to regular speed, it’s like the player Pawn and the AIs all accumulated velocity, so they get pushed away all over the game level.