Улучшаем производительность: boxing в .NET, которого можно избежать

Еще один способ избежать боксинга/анбоксинга в дженерик методах это TypedReferences(работают в моно с 2.10)

static void foo(ref T value)
{

//This is the ONLY way to treat value as int, without boxing/unboxing objects
if (value is int) __refvalue(__makeref(value), int) = 1;
else value = default(T); }

}

и насколько это улучшило производительность?

А профилировщиками или бенчмарками пункты 1-2-3 меряли?

Мне просто хочется посмотреть в своём проекте, насколько большой вклад дают эти вещи в тормоза в целом, и имеет ли смысл срочно ими заморочиться. Хорошо бы знать, как лишний боксинг будет выглядеть в профайлере, например встроенном или джетбрейновском.

Я раньше постоянно из эстетических соображений переписывал стандартные конструкции вида "(a & b) == b" на a.HasFlag(b). До тех пор, пока не запустил профайлер и не обнаружил миллионы ненужных боксов. Ясно, что это короткоживущие объекты, и они уничтожаются практически сразу, но всё-равно я не понимаю, почему разработчики CLR сделали такую кривую реализацию этого метода. Лучше бы вообще не делали.

Здорово! Спасибо за статью. Очень был удивлен по поводу enum-ов. Все время старался использовать именно их в качестве ключа для Dictionary из предположения «легковесности» (по крайней мере мне так казалось) вычисления GetHashCode-а.

Отвечаю сразу на два вопроса по тому, насколько это поможет в ваших проектах. Сложно сказать, я же не видел ваш код. Вообще, как я написал вначале, проблемы производительности обычно лежат на уровень выше и надо просто запускать профайлер и решать одну проблему за другой. Насчет того, как найти в профайлере. В профайлере можно часто увидеть различные value типы в списках объектов, живущих на куче. Если их очень много, и они выходят на первые строки, то надо начинать задумываться. Мы смотрели блокировки и получили такой stack trace (но это я уже забегаю в тему следующей статьи):

1. Первое правило оптимизации: Никогда не занимайся оптимизацией без профилирования!
2. Второе правило оптимизации: Никогда не занимайся оптимизацией без профилирования!
3. Третье правило оптимизации: Никогда не занимайся оптимизацией без профилирования!
4. Если boxing/unboxing стал решающим, значит сервер и так уже супероптимизирован и форматирование строк, например, там вовсе не используется

Утверждается, что боксинг и оператор as дороже, чем два вызова приведения типа: is + (T)?

В WPF, который делает дофига боксов при доступе к свойствам, есть вот такая вещь:

    public static class BooleanBoxes
    {
        public static readonly object True = true;
        public static readonly object False = false;

        [Pure]
        public static object Box(bool value)
        {
            Contract.Ensures(Contract.Result<object>() != null);

            return value ? True : False;
        }
    }

Она internal, но можно добавить код в свой проект и тоже использовать.

При использовании ToString в сочетании с Format есть одна вещь, про которую легко забыть — если форматирование делается не с CurrentCulture (а, например, с InvariantCulture), то его надо передавать и в Format, и во все ToString. Хотя имхо вообще культуру лучше явно передавать всегда там, где есть такая возможность, и настроить варнинги соответствующим образом.

>> Если же метод работает и с value типами и с reference типами, то, например, сравнение на null лучше писать так

Сравнение с null для value-типов в языке определено отдельно, и не приводит к реальному боксингу. Интереса ради можете попробовать сравнить какой-нибудь Int32 с null в не-generic коде, и посмотреть на IL.

Вообще, тут главное помнить, что любой generic метод, если параметром-типом ему передать value-тип, получит отдельную реализацию на уровне JIT, где конкретный T известен — и оптимизатор там порезвится вволю. Из моих личных экспериментов, генерируемый ассемблерный код практически всегда эквивалентен тому, что получается при ручной подстановке.

>> оператор as работает только с reference типами

Это не так — он работает и с nullable value-типами. К вашему случаю это, правда, не относится поскольку нельзя написать T?, если нет struct constraint (кстати, это, наверное, наиболее косячная деталь в реализации nullable в CLR). Но поскольку у value-типа будет своя инстанциация дженерика, я почти стопроцентно уверен, что JIT-оптимизатор выкинет в ней и box, и isinst, и просто подставит там константу. Хотя это надо проверить.