Использование памяти, проблема SortedList vs List

Я использовал SortedList () в классе, который хранит около 15-100K данных.

недавно мои требования изменились, данные больше не должны храниться как отсортированные, поэтому я переключился на List ().

однако в этом случае я заметил, что List () потребляет около 20%+ больше памяти.

9К элементы:

  • парам: 105 МБ
  • список: 125 МБ

15K элементы:

  • парам: 115MB
  • список: 140 МБ

в среде, которую я разрабатываю, память имеет решающее значение. Вместо list (), что я могу использовать, чтобы избежать лишнего потребления памяти и еще не отсортированный список?

P.S. Я использую HashSet (строки) для обеспечения проверки уникальности при использовании List (Of) для имитации SortedList.ContainsKey() хотя я не думаю, что это может принести такой памяти накладные расходы.

П. С. 2: мое приложение имеет около 80 МБ база распределения памяти в автозагрузки. Поэтому числа должны читаться как 105-80=25, 125-80 =45 и так далее

результаты

Спасибо за все ответы, окончательные результаты:

  • вы должны установить правильную емкость для сохранения
  • Hashset очень плохо относится к памяти и потребляет намного больше, чем ожидания. Вот в чем проблема. Как-то SortedList () удается использовать меньше памяти для аналогичной функциональности.

Некоторые Bencmarks: 500 символов, 250000 insert

список(строки)(50000)

274 МС - 226 МБ

SortedList (Строки, Строки) (50000)

34868 МС - 230 МБ

поиска HashSet

420 МС - 232 МБ

словарь(строки, Объект)

486 МС - 234 МБ

хотя, когда я изменил уменьшенное количество до 25, то:

поиска HashSet за 600.000 итерации 300 Мб, где List () составляет 286 Мб

также об использовании памяти Hashset:http://blog.mischel.com/2008/04/09/hashset-limitations/ словарь (строки, объекта) был не намного лучше в моем тесте.

7
.net c# collections memory performance

6 ответов

на List<T> с деталями 9k имел бы емкость между 9k и 18k, поэтому накладные расходы для тех деталей были бы между 36 и 72 килобайтами (двойником на 64-разрядной системе).

очевидно, что 72 КБ даже не близко к разнице в 20 МБ, которую вы видите, поэтому использование памяти самого списка не может быть причиной. Особенно учитывая, что отсортированный список также должен содержать ссылку на каждый объект, поэтому использование памяти должно быть одинаковым.

Итак, либо нет что-то еще использует память, или вы не смотрите на фактическое использование памяти приложения. Если вы смотрите в диспетчере задач, вы не видите, сколько памяти используется, только сколько выделено менеджером памяти.

3

вы предварительно распределяете List<T> мощности?

небольшой эксперимент, который я сделал:

эта программа занимает ~640MB

List<int> list = new List<int>(0);

for (int i = 0; i < 100000000; i++)
{
    list.Add(i);
}

эта программа занимает ~320MB

List<int> list = new List<int>(100000000);

for (int i = 0; i < 100000000; i++)
{
    list.Add(i);
}
9

Если у вас уже есть хэш-набор вашей коллекции, я не уверен, зачем вам нужен список, но если вы ищете контейнер, который гарантирует уникальность и функциональность ContainsKey (), почему бы не общий словарь?

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

2

hashsets том (& хеш-таблицы) использовать много памяти ! Гораздо больше, чем простой список/sortedlist

1

Проверьте коллекции питания Wintellect, эквивалент .NET для коллекций типов STL. Я считаю, что тип набора должен дать вам необходимую функциональность (уникальность), но вам нужно будет сделать критерии для сравнения. Просто мои 2 цента.

0

Я бы рекомендовал посмотреть на застекленные списки (http://sites.google.com/site/glazedlists/). Эти очень быстры для сортировать и больш с памятью.

0