Оптимизация производительности .NET (C#) приложений

Выложите, пожалуйста, код бенчмарка, сравнивающего ToList и ToArray.

Про выравнивание enum'ов не знал, это не противоречит статье, однако с этой точки зрения я даже не оценивал.

На самом деле это касается всех типов. Если вы создадите структуру S с одним свойством типа byte, то sizeof(T) вернет 1. Однако если добавить к ней более длинный тип, например int, то уже sizeof(T) == 8, а не 5 как могло бы показаться. C long будет вообще 16. Т.е. если свойства типа байтового enum будет хотя бы с одним свойством int, то оптимизации по памяти не будет. Выравнивание сделано для оптимизации, так как доступ к выровненным элементам гораздо быстрее. Однако это касается архитектуры x64. На x86, возможно, будут другие цифры.

Если запустить простой бенчарк, то по времени выполнения мы получим эквивалентный результат, нельзя выявить победителя. А вот по выделению памяти ToArray стабильно расходует меньше.

По памяти тоже нельзя что-то сказать однозначно. Ок, давайте сравним код обеих имплементаций на вышеупомянутом https://referencesource.microsoft.com

В методе ToList(this IEnumerable collection) вызывается конструктор списка List(IEnumerable collection), внутри которого происходит перебор коллекции и обычное добавление в список с помощью метода Add, пустая часть не отсекается.

В методе ToArray(this IEnumerable source) вызывается конструктор интернального класса Buffer(IEnumerable source), после чего на результирующем коллекции вызывается метод ToArray(). Buffer работает аналогично List, а метод ToArray, в свою очередь, триммит результирующий массив. Из чего можно я делаю вывод, здесь все же происходит лишняя аллокация.

Кстати, еще более оптимально использовать запись, в которой лишняя коллекция вообще не создается без необходимости:

enumerable as List<Item> ?? enumerable.ToList();

P.S. у вас ошибка — там имелось в виду ToArray, а не ForArray?

Я тоже не до конца понимаю смысла помечать методы агрессивным инлайнингом — это то, что я бы назвал premature optimization.

1. Красивого способа нет и не будет. Я считаю, что это методологически неправильно смотреть только на значения Mean/Median без Error/StdDev. По такой табличке очень опасно делать выводы, т.к. невозможно прикинуть есть ли статистически значимая разница между бенчмарками. Можно легко обмануть себя и другие людей, которые будут смотреть на результаты подобных экспериментов.
   Но если очень-очень хочется, то сделать это всё-таки можно. Нужно скопипастить дефолтный конфиг и поменять реализацию GetColumnProviders (вот тут можно посмотреть что подставляется по дефолту).
2. Такой фичи нет, но она выглядит интересной, можно сделать. Буду рад тикету или пул-реквесту.

Оптимизация есть, просто sealed нужно ставить не в базовом классе.
Если код сильно виртуальный, то подобная оптимизация экономит одно обращение к памяти.
А вместе с инлайнингом работает ещё эффективнее.

ПС. В sealed классе компилятор не выдает предупреждение на использование виртуальных методов в конструкторе.

Но сейчас, sealed класс с виртуальным методом даже не скомпилируется (код ошибки CS0549).

Пример из книги Джеффри Рихтера «CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке C#. Мастер-класс. / Пер. с англ. — М.: Издательство «Русская Редакция»; СПб.: Питер, 2007», который показывает как модификатор sealed влияет на производительность:

Например, в следующем коде JIT-компилятор может вызвать виртуальный метод ToString невиртуально.

using System;
public sealed class Point {
    private Int32 m_x, m_y;

    public Point(Int32 x, Int32 y) { m_x = x; m_y = y; }

    public override String ToString() {
        return String.Format("({0}, {1})", m_x, m_y);
    }

    public static void Main() {
        Point p = new Point(3, 4);

        // Компилятор C# вставит здесь инструкцию callvirt,
        // но JIT-компилятор оптимизирует этот вызов и сгенерирует код
        // для невиртуального вызова ToString,
        // поскольку p имеет тип Point, являющийся изолированным.
        Console.WriteLine(p.ToString());
    }
}