Определенные типы набора в .NET имеют дополнительную "Начальную Способность" параметр конструктора. Например:
Dictionary<string, string> something = new Dictionary<string,string>(20);
List<string> anything = new List<string>(50);
Я, может казаться, не нахожу то, что начальная способность по умолчанию для этих объектов на MSDN.
Если я знаю, что буду только хранить приблизительно 12 объектов в словаре, разве не имеет смысла устанавливать начальную способность на что-то как 20?
Мое обоснование, предполагая, что способность растет как оно, делает для StringBuilder, который удваивается каждый раз, когда способность поражена, и каждое перераспределение является дорогостоящим, почему бы не задать размер к чему-то, что Вы знаете, будет содержать Ваши данные, с некоторой дополнительной комнатой на всякий случай? Если начальная способность равняется 100, и я знаю, что мне только будет нужна приблизительно дюжина, кажется, как будто остальная часть той памяти не выделяется ни для чего.
Если значения по умолчанию не задокументированы, причина, вероятно, в том, что оптимальная начальная емкость - деталь реализации и может изменяться в зависимости от версии фреймворка. То есть вам не следует писать код, предполагающий определенное значение по умолчанию.
Конструктор перегрузки с емкостью предназначен для случаев, когда вы лучше , чем класс, знаете, какое количество элементов ожидается. Например, если вы создаете коллекцию из 50 значений и знаете, что это число никогда не увеличится, вы можете инициализировать коллекцию с емкостью 50, чтобы не пришлось изменять размер, если емкость по умолчанию меньше.
Тем не менее, вы можете определить значения по умолчанию с помощью Reflector. Например, в .NET 4.0 (и, вероятно, в предыдущих версиях),
List
Dictionary
При проверке источника емкость по умолчанию для List
и Dictionary
равна 0.
Если вы знаете размер, то скажите его; небольшая оптимизация в большинстве «маленьких» случаев, но полезна для больших коллекций. Я бы в основном беспокоился об этом, если бы добавлял «приличный» объем данных, так как тогда это может избежать необходимости выделять, копировать и собирать несколько массивов.
В большинстве коллекций действительно используется стратегия удвоения.