I have removed this from ini’s, so I can confirm that the garbage collector is the cause of the peaks.
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?