IDictionary <string, string> или NameValueCollection - PullRequest
31 голосов
/ 06 марта 2009

У меня есть сценарий, в котором я могу использовать либо NameValueCollection, либо IDictionary. Но я хотел бы знать, какой из них будет лучше с точки зрения производительности.

- Использование NameValueCollection

NameValueCollection options()
{
    NameValueCollection nc = new NameValueCollection();

    nc = ....; //populate nc here

    if(sorting)
       //sort NameValueCollection nc here

    return nc;
}

- с использованием IDictionary

IDictionary<string, string> options()
{
    Dictionary<string, string> optionDictionary = new Dictionary<string, string>();

    optionDictionary = ....; //populate

    if(sorting)
       return new SortedDictionary<string, string>(optionDictionary);
    else
       return optionDictionary;
}

Ответы [ 4 ]

29 голосов
/ 06 марта 2009

Эти типы коллекций не являются взаимозаменяемыми: NameValueCollection обеспечивает доступ через целочисленные индексы. Если вам не нужны эти функции, вам не следует использовать NameValueCollection, так как индексирование не происходит «бесплатно».

В зависимости от количества строк, которые вы просматриваете, я бы рассмотрел Hashtable или IDictionary. Кшиштоф Квалина обсуждает здесь тонкости: http://blogs.gotdotnet.com/kcwalina/archive/2004/08/06/210297.aspx.

9 голосов
/ 06 марта 2009

Другое преимущество IDictionary состоит в том, что он не зависит от реализации в отличие от NameValueCollection.

4 голосов
/ 06 марта 2009

Я согласен с fatcat и lomaxx (и проголосовал за оба ответа). Я бы добавил, что производительность типов коллекций, скорее всего, должна быть последним фактором при выборе между типами коллекций. Используйте тип, который наиболее соответствует вашим потребностям использования. Если вы находитесь в критически важной части кода (и, скорее всего, нет), тогда единственный ответ - измерить каждый случай - не верьте Интернету, верьте цифрам.

2 голосов
/ 22 января 2016

NameValueCollection в .NET - это то, что в основном используется для QueryStrings для хранения пар ключ / значение. Самая большая разница в том, когда добавляются два элемента с одинаковым ключом. С IDictionary есть два способа установить значение. Использование метода .Add () вызовет ошибку дублирующего ключа, когда ключ уже существует. Но просто установка элемента равным значению перезапишет значение. Вот как IDictionary обрабатывает дубликаты ключей. Но NameValueCollection добавит такие значения: «значение1, значение2, значение3». Таким образом, к существующему значению элемента добавляется запятая, а затем к нему каждый раз добавляется новое значение.

Мне кажется, что эта коллекция NameValueCollection была создана специально для использования и доступа к QueryString. Строка QueryString, подобная "? A = 1 & b = 2 & a = 3" в .NET, выдаст результат item ["a"] = "1,3". Эта разница в том, как обрабатываются дубликаты ключей, является «реальной» разницей, то есть самой большой разницей между ними.

Я подозреваю , что NameValueCollection также не использует хеш-таблицу для быстрого доступа к ключам, когда коллекция велика, потому что этот доступ медленнее для небольших коллекций, чем без хеш-таблицы. Я не нашел точной информации, которая бы указывала, использует ли NameValueCollection хеш-таблицу для доступа к ключам или нет. Я делаю знаю, что IDictionary использует хеш-таблицу, так что доступ к ключам в IDictionary со многими ключами довольно быстрый. Так что я подозреваю , что NameValueCollection быстрее для небольших коллекций, чем IDictionary. Если мое предположение верно, то это будет означать, что шлюз NameValueCollection ни в коем случае не должен использоваться для больших коллекций, поскольку чем он больше, тем больше он замедляется без хеш-таблицы для доступа к ключам.

Для числа ключей в строке запроса это число обычно очень мало, поэтому я думаю NameValueCollection не использует хэши для повышения производительности. Но если Microsoft спроектировала вещи для производительности и для того, что лучше для их пользователей, Windows будет настолько отличаться от , как сегодня. Так что мы не можем предполагать что-либо, что «должно быть».

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...