[Proposal] Allow take underlying array from a List<T>

[Neo-Ciber94]

Motivation

To extract the data from a List<T> as an array you need to call List<T>.ToArray() which is enough when you need to take the current state of the list and continue modifying it, but what if you just want the array and don't need the List<T> anymore? We are creating a new allocation when you just need the current state of the list.

public int[] ComputeSomething(int max) 
{
    var list = new List<int>();
    for(var i = 0; i < max; i++) {
        list.Add(i * max);        
    }

    // list is not being used anymore
    return list.ToArray();
}

Proposal

Would be great to allow us to just take the inner array of the List<T>

public Span<int> ComputeSomething(int max) 
{
    var list = new List<int>();
    for(var i = 0; i < max; i++) {
        list.Add(i * max);        
    }

     // list is not being used anymore, lets just take the data
    return list.TakeArray();
}

API Design

public class List<T> // ...
{
    internal T[] _items;
    internal int _size;
    // ...

    public Span<T> TakeArray()
    {
        var array = _items;
        var size = _size;

        // Reset this List<T>
        _size = 0;
        _items = Array.Empty<T>();

        // Returns the data
        return new Span<T>(array, 0, size);
    }
}

[HaloFour]

This would be a request for the runtime repository, they deal with the APIs of the base class library.

[Neo-Ciber94]

This would be a request for the runtime repository, they deal with the APIs of the base class library.

Thanks, moved.

[ufcpp]

https://source.dot.net/#System.Private.CoreLib/CollectionsMarshal.cs,b48f5c98e43560f8

[theunrepentantgeek]

Having List<T> provide direct access to the underlying array would be a violation of encapsulation and an invitation to a lot of subtle bugs and data corruption in the name of dubious performance gains.

There's no way to enforce that the reference to the List<T> is dropped after the reference to the array is extracted. This would leave you with two very different references to the same sequence of items, where modification via either would be visible to both.

Plus, in the vast majority of cases, List<T> is the preferred abstraction - it has a lot more flexibility and a far superior API.

My personal experience is that use of ToArray() for performance reasons is almost entirely misplaced - I've frequently been able to make code significantly faster (anywhere from shaving a few % off execution times to making things run 20-100 x faster) by ditching the use of array and writing smarter code using the more powerful API.

[Neo-Ciber94]

Having List<T> provide direct access to the underlying array would be a violation of encapsulation and an invitation to a lot of subtle bugs and data corruption in the name of dubious performance gains.

There's no way to enforce that the reference to the List<T> is dropped after the reference to the array is extracted. This would leave you with two very different references to the same sequence of items, where modification via either would be visible to both.

By invalidating the current items of the List<T> should be enough to ensure you can't modify the reference returned from the list (See updated API Design)

Plus, in the vast majority of cases, List<T> is the preferred abstraction - it has a lot more flexibility and a far superior API.
You could just use List<T> as a builder for an array of unknown size, this way you have the flexibility of List<T> without the need of other custom container.

[theunrepentantgeek]

How are you going to handle the array (almost) never being the exact size for all the items?

The underlying storage of a List<T>, the length of the array, is the Capacity of the list, not the Count.

Resizing the array would involve allocation and copying, so you're stuck between a rock and a hard place. (This is what TrimExcess() does, btw.)

I don't think you can rely on setting Capacity in advance either, as I don't think the API contract is to set the capacity exactly, just to ensure the list can grow to that size without reallocation. (I haven't checked the current implementation.)

Also, if you know the Capacity you need in advance, you can directly allocate an array anyway.

Last observation: do you have benchmarks to show that the reduction in allocations is worth it? Or are you working on intuition?

My experience with measured performance optimisation, well, I've already stated that.

[Neo-Ciber94]

How are you going to handle the array (almost) never being the exact size for all the items?

The underlying storage of a List<T>, the length of the array, is the Capacity of the list, not the Count.

The API could be changed to:

public T[] TakeArray(out int size)
{
      size = _size; // list size

      var array = _items;
      _items = Array.Empty<T>();
      _size = 0;

      return array;
}

This way we get the entire array with current element count.

Last observation: do you have benchmarks to show that the reduction in allocations is worth it? Or are you working on intuition?

My experience with measured performance optimisation, well, I've already stated that.

This is a small benchmark using CollectionsMarshal.AsSpan(List<T>) which is fairly similar:
https://gist.github.com/Neo-Ciber94/d48a563132981486d3ee1a6bd85768b7

Results:

Method	Max	Mean	Error	StdDev	Ratio	RatioSD	Gen 0	Gen 1	Gen 2	Allocated
ToArray	64	365.3 ns	679.83 ns	37.26 ns	1.00	0.00	0.2217	-	-	928 B
TakeArray	64	373.6 ns	488.58 ns	26.78 ns	1.03	0.16	0.1545	-	-	648 B
ToArrayWithInitialCapacity	64	290.3 ns	347.33 ns	19.04 ns	0.80	0.06	0.1779	-	-	744 B
TakeArrayWithInitialCapacity	64	247.9 ns	270.54 ns	14.83 ns	0.68	0.03	0.1106	-	-	464 B
ToArray	128	741.2 ns	288.36 ns	15.81 ns	1.00	0.00	0.4110	-	-	1720 B
TakeArray	128	629.0 ns	576.28 ns	31.59 ns	0.85	0.04	0.2823	-	-	1184 B
ToArrayWithInitialCapacity	128	502.2 ns	427.99 ns	23.46 ns	0.68	0.04	0.3300	-	-	1384 B
TakeArrayWithInitialCapacity	128	420.8 ns	27.06 ns	1.48 ns	0.57	0.01	0.2027	-	-	848 B
ToArray	256	1,453.5 ns	1,499.73 ns	82.21 ns	1.00	0.00	0.7839	-	-	3280 B
TakeArray	256	1,117.7 ns	1,342.71 ns	73.60 ns	0.77	0.07	0.5322	-	-	2232 B
ToArrayWithInitialCapacity	256	948.8 ns	576.27 ns	31.59 ns	0.65	0.03	0.6351	-	-	2664 B
TakeArrayWithInitialCapacity	256	775.4 ns	701.59 ns	38.46 ns	0.54	0.06	0.3862	-	-	1616 B
ToArray	512	2,360.1 ns	1,180.88 ns	64.73 ns	1.00	0.00	1.5221	-	-	6376 B
TakeArray	512	2,162.8 ns	705.05 ns	38.65 ns	0.92	0.02	1.0262	-	-	4304 B
ToArrayWithInitialCapacity	512	1,897.1 ns	738.74 ns	40.49 ns	0.80	0.02	1.2474	-	-	5224 B
TakeArrayWithInitialCapacity	512	1,598.0 ns	2,882.06 ns	157.98 ns	0.68	0.07	0.7534	-	-	3152 B

For the inicial capacity is half of the max.

Not sure what is the criteria to know when an allocation reduction is worth, that could depend of the use case.