Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.

If I understand it correctly, this gives us up to 3.5% imprvoement for the best case - insertion at the 0 index in a large array, right?

If I understand it correctly, this gives us up to 3.5% imprvoement for the best case - insertion at the 0 index in a large array, right?

The gain is 20%-ish for insertion at 0 into 10000-long list.

(InsertRange: 100->100 or 10000->10000)

The correct benchmark should utilize [IterationSetup]. But for the sake of simplicity, I made two benchmarks (one generates the list only, one generates and inserts), and subtract the generation+insertion time with generation-only time.

btw, should we replace Array.Copy with Span.Copy in List when possible? Since there's no type-safety issues. All types are T.

Maybe. It would be a tradeoff between steady state speed vs. and startup time and memory consumption. List<T> is one of the most popular generic types and it does not use span today, except in List.Sort that is very rarely used. If it were to start using span, each List<T> type instantiation would also need to load Span and ReadOnlySpan type instantiations that would regress startup time and increase memory cost of each List<T> instantiation.

This PR is a similar tradeoff at smaller scale. It makes each List<T> type instantiation more expensive to create and take more memory.

Maybe.

I just did a microbenchmark and it seems replacing Array.Copy with Span.CopyTo doesn't have big observable perf impact, even for 10000-long int list. So I removed that reply.

This PR is a similar tradeoff at smaller scale. It makes each List<T> type instantiation more expensive to create and take more memory.

Yes you are right.

I just did a microbenchmark and it seems replacing Array.Copy with Span.CopyTo doesn't have big observable perf impact, even for 10000-long int list.

The bigger impact here would be with smaller collections, since Span.Copy then skips a few checks and allows unrolling.

share updated perf numbers.

public class InsertIntoExisting
{
    [Params(100, 10000)]
    public int Size { get; set; }
    private int[] _array;
    [GlobalSetup]
    public void InitArrayForInsertRange()
    {
        _array = new int[Size];
    }
    public List<int> PrepareList()
    {
        var list = new List<int>(Size);
        var size = Size;
        for (var i = 0; i < size; i++)
            list.Add(i);

        return list;
    }

    [Benchmark]
    public object Baseline()
    {
        return PrepareList();
    }
    [Benchmark]
    public object InsertAt0()
    {
        var list = PrepareList();
        list.Insert(0, 0);
        return list;
    }
    [Benchmark]
    public object InsertRangeAt0()
    {
        var list = PrepareList();
        list.InsertRange(0, _array);
        return list;
    }
    [Benchmark]
    public object Add()
    {
        var list = PrepareList();
        list.Add(0);
        return list;
    }
    [Benchmark]
    public object AddRange()
    {
        var list = PrepareList();
        list.AddRange(_array);
        return list;
    }
}

public class OneByOneTest
{
    [Params(8, 32)]
    public int Size { get; set; }
    [Benchmark]
    public object Prepend_OneByOne()
    {
        var list = new List<int>();
        var size = Size;

        for (var i = 0; i < size; i++)
            list.Insert(0, 0);

        return list;
    }
    [Benchmark]
    public object Add_OneByOne()
    {
        var list = new List<int>();
        var size = Size;

        for (var i = 0; i < size; i++)
            list.Add(0);

        return list;
    }
}

@adamsitnik btw do you have thoughts on how to benchmark this, which requires a new List<T> for every iteration? Obviously I cannot use [IterationSetup] because each iteration is too short (and cannot be extended through loop)

Currently I added a baseline function and subtract results, but it can be unstable and troublesome.

    [Benchmark]
    public object Baseline()
    {
        return PrepareList();
    }

    [Benchmark]
    public object InsertAt0()
    {
        var list = PrepareList();
        list.Insert(0, 0);
        return list;
    }

@karakasa this is tricky. You can combine [IterationSetup] with [InvocationCount] which tells how many times a benchmark should be invoked per iteration and then in every benchmark ivocation, access an n-th List that is pre-configured in the setup. We do that for sorting in dotnet/performance:

https://github.com/dotnet/performance/blob/bc0b657f6a759c4a07589a6b5d66818345813304/src/benchmarks/micro/libraries/System.Collections/Sort.cs#L19

https://github.com/dotnet/performance/blob/bc0b657f6a759c4a07589a6b5d66818345813304/src/benchmarks/micro/libraries/System.Collections/Sort.cs#L37-L45

It doesn't necessarily require a new List. For a small amount of overhead, it could do:

CollectionsMarshal.SetCount(list, 0);
list.Capacity = 0;

or similar to put it back to the desired configuration. It could even use UnsafeAccessor to poke at list internals directly.

Original issue: #89915 (by me)