Ностальгические игры: Проклятые земли

Непонятно, что именно делали разработчики на протяжении пяти лет, но итоговый результат не сильно понравился ни прессе, ни игрокам

ЗвА -- это сторонняя разработка, можно сказать фанатская, пусть и изданная официально. Ребята из любви к игре вытащили этот проект. Там по сути не было Нивала, в том смысле, что именно эта команда делала крутые современные проекты.
Лично мне в ней не понравилось обратное прохождение островов. Жаба сильнее Черной Баньши, ну.. странно. Если б сюжетку получше продумали, наверно игра попала бы в сердечко.

The Elder Scrolls III: Morrowind: чем цепляет эта нестареющая классика?

ох, ПЗ.. Раз в несколько лет прохожу. Ностальгия.

Некоторые аспекты работы с Dictionary при разработке нагруженных приложений

Необязательно. Разница на самом деле не такая существенная, даже с оптимизациями. Во всяком случае не настолько большая, чтоб писать большой и сложный проект на C++.
Тем более в .NET уже даже интринсики перенесли.
Другое дело, что черной магии в платформе многовато. Например, последний опыт (сравнение производительности поиска по словарю и массиву) дал в общем-то аномальный результат, при прямом сравнении у меня обычно получается примерное равенство при 20-30 элементах (оттого и вывел границу в 50), а тут вышло много больше.

Некоторые аспекты работы с Dictionary при разработке нагруженных приложений

А для value типа — копирование. Которое произойдёт при изменении внутренних коллекций.

Ну значит желательно проектировать архитектуру так, чтоб таких изменений было меньше. Заметка как раз об этом.

Тогда это нужно указать явно. А также описать, за счёт чего во втором варианте получился выигрыш по памяти более чем в 2 раза.

Это все указано и написано

Приведёте миллионную хэштаблицу, у которой поиск вырождается?

Да хоть миллиардную). Банально переопределите у ключа

    public override int GetHashCode()
    {
        return 1;
    }

и выродится. Это как раз и есть худший случай для оценки сложности алгоритма.
Если же говорить о более реальной ситуации, то распределение ключей для алгоритма всегда имеет вероятностную, внешнюю природу, алгоритм это не контролирует, как и выбор хэш-функции. Соответственно нет никаких гарантий уникальности хэшей для разных ключей. На миллион ключей может быть как миллион уникальных хэшей, так и множество совпадающих. Дальше степень уникальности еще снижается делением на длину массива _buckets. Опять же нет никаких гарантий, что значения даже для уникальных хэшей в конце концов не попадут на одну позицию в этом массиве. Есть только ожидание, что в большинстве случаев произойдет именно так.

Так или иначе, нужно понимать, какой конкретно процессор имеется в виду, а также, что от процессора к процессору это значение будет меняться.

Исследование разных конфигураций не является темой этой заметки. В остальном же для актуальных процессоров это правило.

Скиньте ссылку, пожалуйста, на документацию, этого я не знал. А какие именно методы перестают быть виртуальными?

Я такой не знаю. Вроде было что-то когда-то в msdn, но кануло. А специально эту тему не исследовал. Просто посмотрел на IL код FindEntry для framework и core. Во втором случае есть определенные оптимизации для типов значений и они действительно дают измеримый эффект (впрочем это не тема данной заметки, просто увидел во время тестов).

Некоторые аспекты работы с Dictionary при разработке нагруженных приложений

Спасибо за комментарий.

Что значит «лучше»? Почему лучше?

В следующем предложении это раскрывается. Хранение ссылочного типа накладно.

… а на массив выдаеляется место в куче.

Само собой.

И зачем её использовать для инициализации больших списков?

Заметка как раз об этом. Не все разработчики понимают, что стоит за некоторыми внешне вполне безобидными строчками кода.

Во-вторых, добавлять миллионы элементов по одному — ну я не знаю, для чего это тестировать и делать какие-то выводы.

А почему нет? Со словарем обычно именно так и работают.

А какой был предыдущий опыт?

Представлен на предыдущем графике.

Я теряю кейс статьи. Только что графики были на миллионы записей, а теперь — на десятки. И совете (выводе?) в конце тоже про «пятьдесят записей».

Угу. Невнятно написал, согласен. В заметке привел несколько наглядных опытов и выводов по ним. Общих выводов в конце нет, только по последнему опыту.

Нет, не помним. Сложность поиска константна. И не при идеальных условиях, а всегда. Константная сложность здесь означает, что значение будет найдено за конечное количество шагов, не зависящее от размера коллекции.

Не означает. Для поиска по хэш-таблицы нет никаких гарантий, что он не выродится в пробег по всей сохраненной коллекции, есть лишь ожидание, что этого не произойдет.

Да причём тут процессор вообще?

Там написано про поиск по массиву. Это один из опытов. При определенном количестве элементов поиск по массиву быстрее. Написано, почему.

Теряюсь в догадках, что это может дать. Так как материализованные generic типы тоже имеют ключ конкретного типа.

Использование явного типа вместо обобщенного позволяет уйти от callvirt, что в свою очередь увеличивает производительность поиска по словарю процентов на 10-20. В некоторых проектах это достаточно важный плюс.

Неуправляемый тип?

Так написано на сайте Майкрософта.
Согласен, часть мыслей выразил скомкано и невнятно. Постараюсь в следующий раз быть внимательней.

Некоторые аспекты работы с Dictionary при разработке нагруженных приложений

Само собой. Я же написал про отдельное место в куче. Отдельное.

Некоторые аспекты работы с Dictionary при разработке нагруженных приложений

Правильно! Но простое число выбирается таким, чтоб было как минимум в два раза больше текущей емкости.

public static int ExpandPrime(int oldSize)
{
    int num = 2 * oldSize;
    if ((uint)num > 2146435069u && 2146435069 > oldSize)
    {
        return 2146435069;
    }
    return GetPrime(num);
 }