Почему это лямбда-замыкание создает мусор, хотя он не выполняется во время выполнения?

I surmise that the compiler or JIT compiler generates the helper class for the lambda for the scope of the method even though I don't understand why this would be desirable.

Рассмотрим случай, когда существует более одного анонимного метода с замыканием в одном методе (достаточно частое явление). Вы хотите создать новый экземпляр для каждого из них или просто сделать так, чтобы все они использовали один экземпляр? Они пошли с последним. У любого подхода есть свои преимущества и недостатки.

Finally, is there any way of caching delegates in this manner without allocating and without forcing the calling code to cache the action in advance?

Просто переместите этот анонимный метод в его собственный метод, чтобы анонимный метод когда этот метод вызывается создавался безоговорочно.

private void Update(int num)
{
    Action action = null;
    //  if (!actionTable.TryGetValue(typeof(int), out action))
    if (false)
    {
        Action CreateAction()
        {
            return () => Debug.Log(num);
        }
        action = CreateAction();
        actionTable.Add(typeof(int), action);
    }
    action?.Invoke();
}

(Я не проверял, произошло ли выделение для вложенного метода. Если да, сделайте его невложенным методом и передайте int.)

Ответ Серви правильный и дает хорошее решение. Я подумал, что могу добавить еще несколько деталей.

Во-первых: варианты реализации компилятора C# могут быть изменены в любое время и по любой причине; Я ничего не говорю, это требование языка, и вы не должны зависеть от него.

Если у вас есть закрытая внешняя переменная лямбда, тогда все закрытые переменные превращаются в поля класса закрытия, и этот класс закрытия выделяется из долгосрочного пула («куча»), как только функция активирован. Это происходит несмотря ни на что того, читается ли когда-либо класс закрытия.

Команда компилятора могла бы отложить создание класса закрытия до первой точки, в которой он был использован: где был прочитан или записан локальный объект, или был создан делегат. Однако это добавило бы к методу дополнительной сложности! Это увеличивает размер метода, делает его медленнее, повышает вероятность того, что у вас будет промах в кеше, это усложняет работу с джиттером, создает больше базовых блоков, поэтому джиттер может пропустить оптимизацию и т. д. Эта оптимизация, скорее всего, не окупится.

Однако команда компилятора делает делает аналогичные оптимизации в тех случаях, когда это с большей вероятностью окупится. Два примера:

• Сценарий с вероятностью 99,99% для блока итератора (метод с yield return в нем) состоит в том, что IEnumerable будет иметь GetEnumerator с именем ровно один раз. Таким образом, сгенерированный перечислимый объект имеет логику, которая реализует как IEnumerable, так и IEnumerator; время первый вызывается GetEnumerator, объект преобразуется в IEnumerator и возвращается. Время второй, мы выделяем второй счетчик. Это сохраняет один объект в наиболее вероятном сценарии, а сгенерированный дополнительный код довольно прост и редко вызывается.
• Для методов async характерно иметь «быстрый путь», который возвращается без ожидания - например, у вас может быть дорогостоящий асинхронный вызов в первый раз, а затем результат кэшируется и возвращается во второй раз. Компилятор C# генерирует код, который избегает создания замыкания «конечного автомата» до тех пор, пока не встретится первый await, и, следовательно, предотвращает выделение памяти на быстром пути, если таковое имеется.

Эти оптимизации имеют тенденцию окупаться, но в 99% случаев, когда у вас есть метод, который выполняет закрытие, он фактически выполняет закрытие. На самом деле не стоит откладывать это.