По крайней мере, до некоторой степени коллекции BCL, похоже, учитывают проблемы с подкачкой.Они также принимают во внимание проблемы с кэшем ЦП (которые частично совпадают, поскольку локальность памяти может влиять на оба, хотя и по-разному).
Учтите, что Queue<T> использует массивы для внутреннего хранения.С точки зрения чисто произвольного доступа (то есть, когда нет никаких затрат на подкачку или очистку кэша ЦП), это плохой выбор;очередь почти всегда будет добавляться только в одной точке и удаляться из другой, и, следовательно, внутренняя реализация в виде односвязного списка выиграет почти во всех отношениях (в этом отношении, с точки зрения итерации по очереди - что она также поддерживает- связанный список не должен работать намного хуже, чем массив в этом отношении в ситуации чистого случайного доступа).Где реализация на основе массива работает лучше, чем односвязный список, именно тогда, когда рассматриваются подкачка и кэш процессора.Эта MS выбрала решение, которое хуже в ситуации чистого случайного доступа, но лучше в реальном случае, когда пейджинг имеет значение, так что они обращают внимание на эффекты пейджинга.
Конечно,со стороны это не очевидно - и не должно быть.Снаружи мы хотим что-то, что работает как очередь;обеспечение внутренней эффективности - другая задача.
Эти проблемы встречаются и другими способами.Например, способ работы GC сводит к минимуму количество страниц, необходимых для подкачки, поскольку его движущиеся объекты не только уменьшают фрагментацию, но и уменьшают количество сбоев страниц.Другие коллекции также реализованы таким образом, чтобы сделать пейджинг менее частым, чем подсказывает самое непосредственное решение.
Это всего лишь несколько вещей, которые выделяются из того, на что я смотрел.Могу поспорить, хорошие деньги, такие проблемы также рассматриваются во многих других местах работы команд .NET.Аналогично с другими фреймворками.Учтите, что одна большая проблема с производительностью, которую Cliff Click неоднократно упоминает в терминах своей хеш-таблицы без блокировок Java (я действительно до сих пор заканчиваю проверять свою реализацию C #), за исключением тех, что касаются параллелизма без блокировок (весь смысл упражнения), это строки кэша;и это также еще одна проблема производительности, которую он не оставляет без внимания!
Учтите также, что большинство видов использования большинства коллекций в любом случае поместятся на одной странице!
Если вы реализуете свою собственнуюколлекции, или использование стандартной коллекции для особо интенсивного использования, тогда вам нужно подумать об этом (иногда «нет, не проблема» - достаточно думать, иногда - нет), но это не значит, что они неуже задумывались о том, что мы получаем из BCL.