GC collections when creating Enumerator from List and IList

Question

I was reading this comment by casablanca in https://softwareengineering.stackexchange.com/a/411324/109967:

There's another caveat here: value types are boxed onto the heap if accessed via an interface, so you'd still incur a heap allocation if enumerating via IList or IEnumerable. You'd have to be holding onto a concrete List instance to avoid the allocation.

I wanted to test this theory using this .NET 5 console app (I've tried swapping between the List<T> and IList<T>):

using System;
using System.Collections.Generic;

namespace ConsoleApp10
{    
    class Program
    {
        static void Main(string[] args)
        {
            IList<int> numbers = new List<int> { 0, 1, 2, 3, 4, 5 };
            //List<int> numbers = new List<int> { 0, 1, 2, 3, 4, 5 };

            for (int i = 0; i < 2000; i++)
            {
                foreach (var number in numbers)
                {

                }
            }
            GC.Collect();
            Console.WriteLine("GC gen 0 collection count = " + GC.CollectionCount(0)); //Always 1
            Console.WriteLine("GC gen 1 collection count = " + GC.CollectionCount(1)); //Always 1
            Console.WriteLine("GC gen 2 collection count = " + GC.CollectionCount(2)); //Always 1
                
        }
    }
}

It appears as though all generations get full and are GCed.

If List<T> uses a struct Enumerator, then there should not be any heap allocations happening up until GC.Collect() is called (afterwards string objects are created in the calls to Console.WriteLine() but that happens after the GC runs).

Question 1: Why are heap allocations happening when using List<T>?

Question 2: I understand that there would be heap allocations due to the reference type Enumerator used when iterating a List<T> via the IList<T> interface (assuming the comment in the linked question is correct), but why does a collection happen in all 3 generations?

2000 Enumerator objects is a lot of objects, but once the foreach loop completes, it's ready to be GCed because nothing is referring to the object after the foreach completes. Why are the objects making it through to Gen 1 and Gen 2?

Answer 1

You're confused by what GC.CollectionCount() is showing you, I think.

Every time you call GC.Collect(), you force a full collection of all generations. You then call GC.CollectionCount(), which is showing you that all generations have just been collected. You're just observing the effects of calling GC.Collect()!

It's true that the IList version is allocating enumerators, but those are dying quickly in gen0.

The proper tool to exmaine this sort of stuff is BenchmarkDotNet with the MemoryDiagnoser.

I put together a simple benchmark:

public static class Program
{
    public static void Main()
    {
        BenchmarkRunner.Run<Benchmarks>();
    }
}

[MemoryDiagnoser]
public class Benchmarks
{
    [Benchmark]
    public int IList()
    {
        int sum = 0;
        IList<int> numbers = new List<int> { 0, 1, 2, 3, 4, 5 };

        for (int i = 0; i < 2000; i++)
        {
            foreach (var number in numbers)
            {
                sum += number;
            }
        }
        return sum;
    }

    [Benchmark]
    public int List()
    {
        int sum = 0;
        List<int> numbers = new List<int> { 0, 1, 2, 3, 4, 5 };

        for (int i = 0; i < 2000; i++)
        {
            foreach (var number in numbers)
            {
                sum += number;
            }
        }
        return sum;
    }
}

This produced the results:

BenchmarkDotNet=v0.13.0, OS=Windows 10.0.19042.985 (20H2/October2020Update)
Intel Core i5-6300U CPU 2.40GHz (Skylake), 1 CPU, 4 logical and 2 physical cores
.NET SDK=5.0.300-preview.21180.15
  [Host]     : .NET 5.0.5 (5.0.521.16609), X64 RyuJIT
  DefaultJob : .NET 5.0.5 (5.0.521.16609), X64 RyuJIT

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
IList	149.42 μs	2.902 μs	3.563 μs	51.0254	-	-	80,128 B
List	48.98 μs	0.961 μs	1.524 μs	-	-	-	128 B

The 128B allocation that's common to both will be the List<T> instance itself. Other than this see how the IList version is allocating about 80KB more, causing 51 new gen0 collections per 1000 operations?