Pay for an allocation/assignments of a capture class regardless of whether it's used

[davkean]

Version: Csc.exe 2.3.0.61907 (ee1637c)

Given:

    class Program
    {
        private void Capture(bool value)
        {
            if (value)
            {
                Method(() => value.ToString());
            }
        }

        private void Method(Action action)
        {
        }
    }

The following is the code gen:

.method private hidebysig instance void  Capture(bool 'value') cil managed
{
  // Code size       46 (0x2e)
  .maxstack  3
  .locals init ([0] class ConsoleApp65.Program/'<>c__DisplayClass1_0' 'CS$<>8__locals0',
           [1] bool V_1)
  IL_0000:  newobj     instance void ConsoleApp65.Program/'<>c__DisplayClass1_0'::.ctor()
  IL_0005:  stloc.0
  IL_0006:  ldloc.0
  IL_0007:  ldarg.1
  IL_0008:  stfld      bool ConsoleApp65.Program/'<>c__DisplayClass1_0'::'value'
  IL_000d:  nop
  IL_000e:  ldloc.0
  IL_000f:  ldfld      bool ConsoleApp65.Program/'<>c__DisplayClass1_0'::'value'
  IL_0014:  stloc.1
  IL_0015:  ldloc.1
  IL_0016:  brfalse.s  IL_002d
  IL_0018:  nop
  IL_0019:  ldarg.0
  IL_001a:  ldloc.0
  IL_001b:  ldftn      instance void ConsoleApp65.Program/'<>c__DisplayClass1_0'::'<Capture>b__0'()
  IL_0021:  newobj     instance void [mscorlib]System.Action::.ctor(object,
                                                                    native int)
  IL_0026:  call       instance void ConsoleApp65.Program::Method(class [mscorlib]System.Action)
  IL_002b:  nop
  IL_002c:  nop
  IL_002d:  ret
} // end of method Program::Capture

Notice that you pay for the creation/assignment of the capture class regardless of the branch in the method. This results in unexpected allocations, such as: #20775

[davkean]

I noticed that the code gen basically treats the capture class's field as if it was the parameter - if I use parameter elsewhere, then the compiler gens that as a read of the field from the capture class. Based on that, this looks very deliberate code gen and probably not overlooked.

[jaredpar]

Based on that, this looks very deliberate code gen and probably not overlooked.

Correct. This behavior is deliberate. The capture logic is entirely scope based and as an optimization it merges empty capture scopes into scopes which capture actual variables. In this case the scope which allocations the delegate has no captured variables and is hence "empty". The compiler optimizes the situation by merging the captures into a single scope, the one where value lives.

That being said, this is a frequent source of confusion amongst users. Additionally the logic around merging scopes was also done when we had a very different pattern for allocating closure types. It made a lot more sense in that context, possibly less in the current one.

@agocke is looking at this as a possible source of optimization in 15.5 when we are revisiting our capture code whole sale. Will let him dupe this against any bugs he may already have filed here.

[jaredpar]

CC @khyperia as an FYI as well