Что более эффективно: List .add () или System.Array.Resize ()?

Question

Я пытаюсь определить, когда это более эффективно List<T>.Add() по сравнению с использованием Array.Resize() метод

В документации для Array.Resize говорится, что он делает копию всего массива и помещает ее в новый объект. Старый объект должен быть отброшен. Где находится этот старый объект? В стеке или кучи?

Я не знаю, как работает list.add ().

Кто -нибудь знает, как метод списка. Адд сравнивается с методом статического массива. Резюме?

Я заинтересован в использовании памяти (и очистке), и что лучше для 300 типов значений, а также 20 000 типов значений.

Что бы это ни стоило, я планирую запустить этот код на одном из встроенных вкусов .NET. Потенциально .NET Гаджера

Answer 1

Вы должны использовать List<T>.

С использованием Array.Resize заставит вас расширять массив отдельно каждый раз, когда вы добавляете элемент, делая свой код много помедленнее. (Поскольку массивы не могут иметь запасную емкость)

А List<T> поддерживается массивом, но держит запасные возможности, чтобы поместить предметы.
Все, что нужно сделать, чтобы добавить элемент, - это установить элемент в массиве и увеличить его внутренний size прилавок.
Когда массив будет заполнен, список удвоит его емкость, что позволит будущим предметам снова добавить легко.

Answer 2

Micro Framework .net не поддерживает дженерики, поэтому я буду использовать массив, копировать и уничтожать его по мере необходимости.

Я мог бы сравнить это Perfmance с развернутым связанным списком, упомянутым в библиотеке PowerTools здесь:Любая реализация развернутого связанного списка в C#?

Answer 3

Micro Framework .net не поддерживает дженериков. Вы ограничены в отношении динамических коллекций.

При выборе вашего подхода является то, что управляемый код на микроконтроллере очень, очень медленный. Многие операции в управляемых объектах .NET Micro Framework на самом деле просто вызывают натуральный код для выполнения работы. Это намного быстрее.

Например, сравните копирование элемента массива по элементу в цикле для петли и вызова Array.copy (), который по сути делает то же самое, но в натуральном коде.

Там, где это возможно, используйте эти нативные расширения, чтобы получить лучшую производительность. Также подумайте о том, чтобы взглянуть на Проект Microlinq на Codeplex. Существует суб -проект, посвященный только расширенным коллекциям NETMF (также доступен в качестве Nuget Package) Код свободно доступен и открыто лицензирован для любой цели. (Полное раскрытие: я разработчик этого проекта.)

Если вы можете уйти с распределения большого массива и отслеживания максимальной позиции, в которой были сохранены реальные данные, это было бы самым быстрым, но требует большей работы / мысли, вставленной в дизайн, и отнимает время от создания прохладных вещей.

Answer 4

Список будет только быстрее, если вы часто изменяете размер массива, например, каждый раз, когда добавляете элемент. Однако, если вы измените его размер каждые несколько кадров, список и встроенные массивы должны быть эквивалентны, возможно, массивы все равно быстрее.

Answer 5

Я видел реализацию списка после декомпиляции и обнаружил, что он использует array.resize () для внутреннего массива. Но он управляет счетчиком элементов и использует длину массива в качестве емкости и изменяйте размер массива с некоторым дополнительным пространством, когда вы называете add (). Итак, я думаю, вы можете разработать более оптимальную стратегию распределения, чем список для вашего дела. Но вам придется управлять элементами против вручную. Кроме того, вы избавитесь от накладных расходов на индексеров при доступе к элементам массива, потому что индексеры внутри списка являются просто методами, которые запрашивают элементы внутренних массивов. Я думаю, что стоит заменить список на массив с ручным размером, если он только в узком месте.