4

I was working on a game with a lot of AI and noticed that my garbage collector was collecting objects 3-4 times a second which was really hurting performance and limiting the enemy count to 120 before the frame rate dropped. I profiled the code and found the culprit to be my collision detection code where I had a function being called multiple times a frame that was generating a list of projections onto axes. The code was like

public List<Vector2> foo()
{
    List<Vector2> projections = new List<Vector2>();

    // Calculate and return projections
}

There were a few other functions creating new lists every call as well and I switched out the generation of new lists each function call in favour of having a list of vector2s stored as a field of the class so that I am not calling new list every function call. This reduced the the garbage collections calls from 3-4 times a second to once every 10-20 seconds, allowing me to get 400-500 enemies on the map before frame rate dropped.

The new functions would have looked like:

public List<Vector2> foo()
{
    // projections is now a field of this class so we just clear it each function call
    projections.Clear();

    // Calculate and return projections
}

My question is why does the List.Clear method incur way less garbage collections than List = new List()? I have done some research into what happens to items in a list when you call clear and it appears as if they should be garbage collected as well when they have no references anymore, so my items are being created inside the function so when that function exits and the list is cleared next call, shouldn't the previous items be garbage collected as well?

My understanding is that the items cleared should be garbage collected just like when I call List = new List. Clearly something else is going on as my garbage collections drastically reduced when I switched to List.Clear(). Here are the links I used for trying to understand whats happening to my list items.

Rui Jarimba
  • 11,166
  • 11
  • 56
  • 86
Darcy
  • 43
  • 4
  • How are you testing garbage collection? – ProgrammingLlama Jun 17 '18 at 10:21
  • @john I’m using visual studio 2015 community. I’m using the profiler to show memory usage and it has lifetime where it has an indicator for each time the garbage collector is called. – Darcy Jun 17 '18 at 11:21

1 Answers1

8

When you clear a list, you're just setting the count to 0 and wiping the existing contents (which makes the old objects possibly collectable, if they are reference-types). The existing buffer (T[]) is retained, and can be reused for the next set. I'm guessing you usually have roughly the same number of projections each frame, so that means the same array can be used pretty much forever

However: if you new it, then a new default-sized buffer is allocated - it starts at something like 10 or 20, IIRC (edit: it looks like it is 4 now). As you add (Add) items, whenever it runs out of room, it will have to resize that buffer (it uses a doubling algorithm, so when you add the 21st item it'll double to 40, etc). If you have a lot of projections, this could mean allocating (and re-copying) a lot of times - so you could allocate a bunch of arrays that end up getting discarded... and of course the single list object.

It is these discarded "double it when it gets full" buffers of size 4, 8, 16, 32, 64, 128, 256, 512, 1024 etc - plus the actual list objects themselves - that you are seeing being collected; not your game objects.

In particlar: Vector2 is a struct, I believe - so: there is nothing to collect!

That can really add up!

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • as a side note; every time it has to resize the buffer to add a new item, it *also* has to do a block-copy of the old data from the old buffer to the new buffer, which can start to get expensive; having a roughly-right-sized array already means that you **never** have to do this – Marc Gravell Jun 17 '18 at 11:14
  • as an extra question, would object pooling be the more appropriate solution compared to having a local field for each list I need in different classes? – Darcy Jun 17 '18 at 11:25
  • @Darcy field per instance is simple; pooling requires lots of management; either can be fine - it really depends on usage. One nice thing about per instance is that the size will usually be about right between frames; if you pool, there's not much guarantee about the size of a pre-existing buffer – Marc Gravell Jun 17 '18 at 11:44
  • I’d say, passing an appropriate initial capacity to the `List`’s constructor would achieve the same without the need for an instance field. Depending on other factors, it may be even more efficient. – Holger Jun 22 '18 at 12:05
  • 1
    Under the hood, calling clear just calls `Array.Clear` on the underlying exception and resets Size to 0 (Capacity remains the same). As with any `List` mutations, it also increments the `_version` to force an exception on active enumerators. – Brian Jun 28 '18 at 15:23