Какой контейнер C # наиболее эффективен для существования только для одной операции? - PullRequest
8 голосов
/ 14 мая 2010

Я часто нахожусь в ситуации, когда мне нужно выполнить операцию с набором свойств. Операция может быть чем угодно, начиная от проверки, соответствует ли конкретное свойство чему-либо в наборе, до одной итерации действий. Иногда набор генерируется динамически при вызове функции, некоторые построены с помощью простого оператора LINQ, в других случаях это жестко заданный набор, который всегда останется неизменным. Но всегда существует одна константа: набор существует только для одной операции и не имеет смысла до или после нее .

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

Ответы [ 3 ]

6 голосов
/ 14 мая 2010

С вашим признанием того, что это больше касается согласованности кодирования, а не производительности или эффективности, я думаю, что общей практикой является использование List<T>. Его реальным резервным хранилищем является массив, так что вы не сильно теряете (если что-то заметное) накладные расходы контейнера. Без большей квалификации я не уверен, что смогу предложить что-то большее.

Конечно, если вы действительно не заботитесь о том, что перечислите в своем вопросе, просто введите переменные как IEnumerable<T>, и вы имеете дело с реальным контейнером только тогда, когда вы его заполняете; где вы потребляете, оно будет полностью согласованным.

2 голосов
/ 14 мая 2010

В отношении эффективности использования ресурсов следует учитывать два основных принципа.

  • Сложность выполнения
  • Объем памяти

Вы сказали, что индексы и порядок не имеют значения и что частая операция совпадает. A Dictionary<T> (который является хеш-таблицей ) является идеальным кандидатом для этого типа работы. Поиск по клавишам выполняется очень быстро, что будет полезно в вашей операции сопоставления. Недостатком является то, что он будет занимать немного больше памяти, чем было бы строго необходимо. Обычно коэффициент загрузки составляет около 0,8, поэтому мы не говорим об огромном увеличении или о чем-либо.

Для других ваших операций вы можете обнаружить, что массив или List<T> - лучший вариант, особенно если вам не нужен быстрый поиск. Пока вам не требуется высокая производительность при выполнении специальных операций (поиск, сортировка и т. Д.), Трудно превзойти общие характеристики ресурсов контейнеров на основе массива.

0 голосов
/ 14 мая 2010

Список, вероятно, хорошо в целом. Это легко понять (в смысле грамотного программирования) и достаточно эффективно. Коллекции с ключами (например, Dict, SortedList) вызовут исключение, если вы добавите запись с дублирующим ключом, хотя это может не быть проблемой для того, над чем вы сейчас работаете.

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

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

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