Download

About garbage collector efficiency using local variables

in your log does is say anything about the GPU and it being delayed by 500ms?

Also make sure you do not have a timer firing over and over that should not be. That will cause lag spikes. I had a timer set to true, i had coded it wrong and every time it fired it would cause a lag spike.

I guess the next thing I would try is a default UDK install and see if the lag spike is present. In which case, this would be a fundamental issue with UDK (or perhaps an issue with hardware you’re running it on). This seems unlikely, but probably best to check before you go down a debugging rabbit-hole.

Gamepainters, I had that problem with the (exactly) 500 ms in an old PC, when using two monitors. I remember it was corrected by returning to an older nvidia driver. In the PCs that I have now it does not happen.

I use a lot of timers, but they don’t seems to be the problem.

Coldscooter, you are right, I think I have to test it in a new UDK installation, because in the current I have the problem even using a blank map with UTgame.
Maybe it is some parameter of the ini, which I modified a lot to do tests.
I have a copy of the inis before modifying them, I’ll test that before doing a new install. And I will tell you the result.

Thank you both for your help.

@ CobaltUDK How often does this happen? Does it repeat every so often? like say every 20 seconds or is there a pattern to it? If so check your true timers set for that repeating time. If it is a timer you will find it that way.

Every 30 seconds, but I haven’t any timer of 30 seconds. And that happen even in a blank map using UTgame.
I think it’s any modification I did in the config files. I will try with a new UDK installation.

Suspicious… Have you ruled out Win10 being the cause??? Examples 1 2.
Like developers needed more reasons to consider airgapping Windows! :rage:

by now I suggest you try it with a cooked game and rule that out

@ CobaltUDKThat sounds like the GPU 500ms lag time. It was happening every 30 seconds or it did on my setup. That was caused by old drivers or old hardware, as you pointed out. Yeah, do a fresh install of udk and see what happens.

Edit: After reading what UnrealEnterprise put up i bet that is your problem.

Edit: Thought just came to me, are you experiencing this on any other games or software? If so, you have hardware issue getting ready to really show up. Check for bad caps on mother board and smps. If you see that then that is your issue. Also check your fans for being plugged with dust, that will cause what you are describing as its causing the ics to get to hot.
Usually the 1st sign of bad caps are, when caps start to go bad is repeating lag type spikes(dirty voltages leaving ac on the dc line and getting into the chips(not good for the chip, it causes it to get to hot and possibly chip damage, which results in lag type spikes)). until they get real bad and the lag will get worse until whatever it is goes out for good.

I think is not the 500 ms GPU problem. I had this in an old PC, but now the peaks are much shorter.

I have tested it in two PCs and in both there are peaks:

  • PC with Win7, i7 4790K + GTX 970.
  • Laptop with Win10, i7 10870H + GTX1660 Ti.

I think is a problem with my UDK installation (with UTgame in a blank map ocurrs too). I’m going to try with a new installation, and with a cooked game as Chosker said, if I can solve memory problems.

Figure out the problem?

Not yet, but I plan to test in the next few days.

I’ll start by updating drivers and restoring the config files.
The next step will be to test in a new UDK installation.
And if it doesn’t work, I’ll try with an older UDK version.
I have 3 pcs where I can test, with different OS and cpu & gpus.

I will tell you here the result.

I have removed this from ini’s, so I can confirm that the garbage collector is the cause of the peaks.

Suppress=DevGarbage

From the log, running the stand alone game (not cooked) in the map game with about 1100 pawns.

[0081.10] DevGarbage: Collecting garbage
[0081.14] DevGarbage: 46.406791 ms for realtime GC
[0081.15] DevGarbage: 3.121443 ms for unhashing unreachable objects
[0081.18] DevGarbage: GC purged 1097 objects (320302 → 319205)

[0111.10] DevGarbage: Collecting garbage
[0111.14] DevGarbage: 43.822400 ms for realtime GC
[0111.15] DevGarbage: 2.221245 ms for unhashing unreachable objects
[0111.18] DevGarbage: GC purged 0 objects (319205 → 319205)

[0141.12] DevGarbage: Collecting garbage
[0141.16] DevGarbage: 43.819640 ms for realtime GC
[0141.16] DevGarbage: 2.217483 ms for unhashing unreachable objects
[0141.20] DevGarbage: GC purged 0 objects (319205 → 319205)

The GC takes almost 3 frames (43 ms) to do it’s work, even there are no objetc to purge.

Seems that the problem is to iterate all the objects because there is no big difference when 0 objetcs are purged. There are 320000 objects in this map, but using the UDK default map there are about 115000 objects and the peak is about 16 ms.

So, there are some way to reduce this, marking objects as no GCable or something?

I assume that static meshes have bmovable = false and bnodelete = true, but this affects to GC?

There is any way to do the recollection distributed in several ticks instead do all it in a frame?

do you have these comments in your player controller file?
// “force garbage collection while dead, to avoid GC during gameplay”
or
// “force garbage collection when possessing pawn, to avoid GC during gameplay”

Yes, these are in UTPlayerController.

Only does a “WorldInfo.ForceGarbageCollection(bool);”, I have tested this function manually, and only does a CG in that time.

But it does not prevent it from doing it every 30 seconds. I think that these lines are to force a GC in some moments, for example when you enter or exit from a menu or pause, to minimize the hitching.

According to the Epic documentation, it is impossible to avoid GC, but you have to try to have the minimum number of objects to check so that the peak is not too high.

Currently I have about 300,000 objects in the map, the peak is about 45 ms. But in a blank map with UTgame there are 115,000 objects and the peak is 16 ms, for only a floor and a cube meshes (was a surprise for me to see the high number of objects in the world).

if you go to content browser and go to the scene tab how many show in that? My biggest map is 2734 items in the scene. Where do you find the total amount of objects in the map? it looks like scene covers everything in my map but the player and weapons and menu stuff.

I think you are talking about actors, not objects (although actors are objects too).

I have 259 actors in the persistent level, and in the city stream level, about 1600 actors. In game, about 1200 NPCs are loaded. So they can be about 3100 actors loaded once.

But it seems that every actor has a lot of objects attached (skelmesh component, voices, LE, etc).

The engine blank map has about 115,000 objetcts, and there are only a floor, a cube, sky, lights, fog… and no much more.

I have searching for this problems and I found some UE3 games with the same issue, and some players talks about changing valours in the ini’s:

[Core.System]
MaxObjectsNotConsideredByGC
SizeOfPermanentObjectPool

But no changes in my case. Perhaps in the cooked game.

I have found this too:
TimeBetweenPurgingPendingKillObjects = 30

I have incremented to 120 and seems to work fine, the hitch is higher (from 50 ms to 62 ms) due more objects to purge, but happens every 2 minutes instead 30 secs. I think is a good deal.

I’m going to increment to 600 to see what happens. I can do a GC manually for example when open the pause or inventory, or the player is idle.

First test:

[0902.62] DevGarbage: Collecting garbage
[0902.67] DevGarbage: 50.814915 ms for realtime GC
[0902.80] DevGarbage: 133.373119 ms for unhashing unreachable objects
[0903.70] DevGarbage: GC purged 261649 objects (591699 → 330050)

objects purged takes 133 ms, instead 3 or 4. The peak is higher, but it’s one time every 10 minutes. The game seems stable, also the RAM.
if there are no unexpected problems, it seems like a good solution.

we have those two set to 0

[Core.System]
MaxObjectsNotConsideredByGC=0
SizeOfPermanentObjectPool=0

and this at 60

TimeBetweenPurgingPendingKillObjects=60

The two firts parameters don’t affect nothing in my case, same objects to chech, same times, etc. I have to test them with a cooked game.

With time between purging i’m doing tests with a value of 600. Works fine, stable. The times are x3, about 150 ms every check instead 50, but every 10 minutes instead every 30 seconds. Perhaps a value of 300 is more reasonable.

The iteration time is the same, but the purge time is bigger because there are more objects acumulated to delete.

There are some forced GC by the engine, for example when a stream level is loaded.
I was wondering why the engine took so long to load a stream level even if it was very small… I didn’t know that a GC was done before.

So, this is the bad part, more objects to purge when a stream level is loaded.

good to see you figured it out. Always nice to solve an irritating problem.