new PooledList<PlayerState>(Players.Count, preallocate : true)

Is your feature request related to a problem? Please describe. Zero overhead structs clone.

Describe the solution you’d like

            PooledList<PlayerState> players = null;
            if (Players != null)
            {
                players = new PooledList<PlayerState>(Players.Count, preallocate : true); // i guess preallocated just sets _size = capacity;
                for (var i = 0; i < players.Count; i++)
                {
                    PlayerState.Clone(in Players.Span[i], ref players.Span[i]);
                }
            }

Describe alternatives you’ve considered

            PooledList<PlayerState> players = null;
            if (Players != null)
            {
                players = new PooledList<PlayerState>(Players.Count);
                for (var i = 0; i < players.Count; i++)
                {
                    // Clone will fail until
                    players[i] = default; // overhead to create 200+ byte struct on stack and pass it into indexer (not sure if optimized away by compilers?)
                    PlayerState.Clone(in Players.Span[i], ref players.Span[i]);
                }
            }

Additional context Usual List could not do that because it would leak abstraction (that it is actually array list). PooledList already leaks Span as property and ArrayPool as ctor arg(also ctor arg is no of so problem). So adding that method will not increase leakage, but will allow more performance uses for structs.

[jtmueller]

Technically you don’t have to pass the count 2 times: just don’t pass anything into the constructor, because one line later you’re setting the capacity. But I get that two lines of code isn’t as nice as one line of code, and maybe adding more constructor overloads would be worth it.

However, there’s another thing to consider when pre-allocating that your sample code doesn’t account for. What if the array we get from the pool already has values in it? In the current published code this doesn’t matter, because the only way to move the internal _size pointer is to overwrite whatever is currently in the array we rented.

By using preallocate to directly move the _size pointer, we’re exposing the random contents of pooled arrays to users who are probably expecting a newly-created list to only have default values in it. This probably means that when preallocate == true we should clear the array we just rented. Do you see this as a performance problem?

[jtmueller]

I like your initial proposal. I think it’s better than the alternative. If you’re willing to submit a PR for it, I would welcome that.