Unnecessary allocation for `[element]` expression

[znakeeye]

Targeting .NET 10. Consider the sample below. (Might be related to #78106.)

In a simple switch expression, I return an IEnumerable<char> for a bunch of known values. For unknown values, I want to fulfill the contract of the enumerable, so I use the nice collection expression syntax to return [c]. Looks nice, but on a very hot path, I noticed significant GC.

Question

Turns out that the collection expression allocates a temporary array, apparently for no reason. Shouldn't the optimizer/jitter be able to optimize away this allocation?

Sample project

Obviously a lot simplified compared to my real world example.

namespace SingleElementCollectionAllocation;

internal class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(GetCharacters("WHATEVER"));
    }

    private static IEnumerable<char> GetCharacters(string s)
    {
        return s.SelectMany(Unwanted_Collection_Allocation);
    }

    private static IEnumerable<char> Unwanted_Collection_Allocation(char c)
    {
        return c switch
        {
            'X' => DoubleUp(c),
            // Unwanted allocation here:
            // IL_000f:  newobj     instance void class '<>z__ReadOnlySingleElementList`1'<char>::.ctor(!0)
            _ => [c]
        };
    }
    
    private static IEnumerable<char> Ugly_Syntax_But_No_Collection_Allocation(char c)
    {
        return c switch
        {
            'X' => DoubleUp(c),
            _ => SingleElementHelper(c)
        };
    }

    private static IEnumerable<char> SingleElementHelper(char c)
    {
        yield return c;
    }

    private static IEnumerable<char> DoubleUp(char c)
    {
        yield return c;
        yield return c;
    }
}

Generated IL code

.method private hidebysig static class [System.Runtime]System.Collections.Generic.IEnumerable`1<char> 
        Unwanted_Collection_Allocation(char c) cil managed
{
  // Code size       23 (0x17)
  .maxstack  2
  .locals init (class [System.Runtime]System.Collections.Generic.IEnumerable`1<char> V_0)
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.s   88
  IL_0003:  bne.un.s   IL_000e
  IL_0005:  ldarg.0
  IL_0006:  call       class [System.Runtime]System.Collections.Generic.IEnumerable`1<char> SingleElementCollectionAllocation.Program::DoubleUp(char)
  IL_000b:  stloc.0
  IL_000c:  br.s       IL_0015
  IL_000e:  ldarg.0
  IL_000f:  newobj     instance void class '<>z__ReadOnlySingleElementList`1'<char>::.ctor(!0)
  IL_0014:  stloc.0
  IL_0015:  ldloc.0
  IL_0016:  ret
} // end of method Program::Unwanted_Collection_Allocation

[RikkiGibson]

Are you saying that a specialized type should be used which requires only one heap allocation, instead of two (for the array and for the wrapper class)?

[znakeeye]

All I'm saying is that dotnet/runtime#15136 is becoming more relevant now that developers can get nice syntax using [element] - unknowingly introducing extra GC pressure.

This example was from a real world application where I got performance degradation on a hot path. Apparently, yield return for single item has better memory characteristics than [element]. Thus, I'm suggesting that the compiler should detect this and compile Enumerable.One() equivalent code instead of the array allocation. Or at least warns about the allocation problem.

PS. If you're referring to the "yield" wrapper class, I'd say it's irrelevant. One allocation vs N array allocations in this case.

[CyrusNajmabadi]

Looks nice, but on a very hot path, I noticed significant GC.

Note: if you are gc sensitive, i would replace all of these with statics.

Also... that you're just returning IEnumerables for these small cases, and doing things like SelectMany is going to add massive overhead for things like character processing.

i'm hesitant about over fixating on this as really i think the original code should be revamped to not require dynamic allocations, or interface dispatch, at all.

[znakeeye]

Looks nice, but on a very hot path, I noticed significant GC.

Note: if you are gc sensitive, i would replace all of these with statics.

Also... that you're just returning IEnumerables for these small cases, and doing things like SelectMany is going to add massive overhead for things like character processing.

i'm hesitant about over fixating on this as really i think the original code should be revamped to not require dynamic allocations, or interface dispatch, at all.

Valid points indeed.

[DoctorKrolic]

Turns out that the collection expression allocates a temporary array

That doesn't seem to be the case, I see no newarr instruction in the IL you provided

// Unwanted allocation here:
// IL_000f: newobj instance void class '<>z__ReadOnlySingleElementList`1'::.ctor(!0)
_ => [c]

That is a creation of the wrapper type for the resulting IEnumerable<char>. If we reduce your example to just collection expression itself, it will have "perfect" IL - just an allocation of a special wrapper type around the element. Nothing can be better. We have to allocate that wrapper type since IEnumerable<T> is an interface, so it is a reference type.

If we go back to your original statement about array allocation it would make sense if the wrapper type was created around an array, so that first an array is allocated, then the element is assigned at its first index, then it is wrapped in an unspeakable IEnumerable<T> wrapper. But the compiler is alredy smart enough to special-case single-element collections, so it generates specific wrapper type for that purpose.

Given everything above, I bevieve, this issue should be closed as "not planned", there is nothing we can improve here

[CyrusNajmabadi]

I agree with @DoctorKrolic i don't see an array allocation in the IL you provided. Can you clarify?