Какая разница в производительности между Microsoft.VisualBasic.Collection и .NET System.Collections.Generic.Dictionary (Of TKey, TValue) известна?

Question

Я работаю над довольно крупным проектом для торговой компании в Филадельфии. Компания использует алгоритмы автоматической торговли, которые обрабатывают потоковые котировки и отправляют котировки для сотен продуктов десятки раз в секунду. Очевидно, что производительность является серьезной проблемой. (Это заставляет меня задаться вопросом, почему мы используем VB.NET, но это совсем другая тема.)

Я относительно новичок в компании и работаю с другим парнем над каким-то кодом, который существует уже некоторое время. Этот код использует объект Microsoft.VisualBasic.Collection для хранения всех продуктов (объектов, представляющих пары ETF или акций и большого количества данных о каждом) и выполняет МНОГО поиска / извлечения из этой коллекции.

Насколько я понимаю, класс Collection устарел, и почти никто больше его не использует. В нашем более свежем коде мы использовали коллекции .NET, такие как List (Of T) и Dictionary (Of TKey, TValue), и, насколько я понимаю, возможно, имеет смысл заменить старую коллекцию Dictionary. Тем не менее, поскольку исходный код довольно существенен, продвижение с этой заменой будет значительным мероприятием; и поэтому мой вопрос заключается в следующем:

Кто-нибудь измерял разницу в производительности между старой коллекцией и словарем .NET? Такое сравнение по какой-то причине неуместно? Конечно, кажется, что все, что мы в настоящее время делаем с Коллекцией, мы могли бы делать со Словарём; в основном я просто хочу знать, имеет ли смысл для нас проходить через код и делать этот переход, или если это по сути будет пустой тратой.

EDIT : Первоначально в вопросе я ссылался на текущую коллекцию, которую мы используем в качестве коллекции VB6. Прочитав первые два ответа, я понимаю, что это более точно Microsoft.VisualBasic.Collection, который представляется классом, представленным для совместимости между VB6 и VB.NET. Я думаю, что вопрос все еще остается в силе.

Основываясь на первой ссылке, приведенной в ответе Кеннета Кохрана, я убежден, что словарь действительно лучше подходит для наших целей, чем коллекция, так как он лучше справляется с извлечением элементов по ключу и выполнением циклов «Для каждого» по несколько миллисекунд на 10000 пробежек. В нашей компании это реалистичный сценарий; в коде много мест с такими утверждениями:

Dim ETF as ETFdetails = ETFcoll(sym)

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

Что-то явно не так с тем, что я только что сказал? Если это так, укажите это!

Answer 1

Если вы используете VB.NET, вы не используете коллекции VB6. Коллекция VB.NET функционально эквивалентна коллекции VB6, но они не совпадают. http://www.vbmigration.com/Blog/post/2008/11/Speed-up-your-VBNET-collections.aspx сравнивает различные типы коллекций .NET с коллекцией VB6, включая коллекцию VB.NET. Каждый тип коллекции имеет свои сильные и слабые стороны (почему бы у нас не было так много типов коллекций на выбор). Некоторые быстрее и вставка за счет поиска и наоборот. Некоторые быстрее с небольшими коллекциями, другие быстрее с большими коллекциями. Ваш выбор должен зависеть от того, какой атрибут производительности наиболее важен для вас.

Вот таблица, на которую я наткнулся, которая показывает относительную производительность стандартных типов коллекций .NET. Обратите внимание, что коллекция VB.NET не включена: http://www.artima.com/forums/flat.jsp?forum=152&thread=179998

Answer 2

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

Алгоритмическая сложность обеих структур данных - O (1).

Answer 3

В работе VB.Net нет ничего плохого. Он компилируется в тот же IL, что и C #, который, в свою очередь, JIT-компилируется в машинный язык. Вот почему он называется .Net Framework , а не .Net VM .

Хотя я не видел непосредственного сравнения VB6 Collection с VB.Net Dictionary, я ожидал бы, что они будут похожи, поскольку основной алгоритм по сути является хеш-таблицей в любом случае. Тем не менее, если будет небольшая разница, я склонен дать преимущество Словарю, потому что здесь нет привязки к кастингу / позднему связыванию. Система будет тратить меньше времени на проверку или перевод типов.

Конечно, это предполагает, что вы используете VB.Net строго типизированным способом с включенными Option Strict и Option Explcit.

Answer 4

Это старый вопрос, но я надеюсь, он все равно поможет ..

Согласно http://msdn.microsoft.com/en-us/library/vstudio/ms172875(v=vs.100).aspx

Тип элемента. Коллекция Visual Basic поддерживает элементы типа Объект, который не является типобезопасным, потому что вы можете добавить элемент любого тип данных. Это обычно приводит к снижению производительности, потому что Компилятор должен блокировать и распаковывать элементы, чтобы конвертировать их в и из Тип данных объекта . Некоторые из коллекций .NET Framework также имеют элементы типа Object, но многие другие строго типизированы, что означает они поддерживают элементы определенного типа, что делает их безопасными для типов и обычно приводит к оптимальной производительности.

Вопрос в том, нужно ли вам хранить различные типы объектов внутри этой коллекции.

Я сделал тест. У меня есть несколько вложенных Microsoft.VisualBasic.Collection, и программа повторяет около 6600 раз, чтобы найти элемент внутри этих коллекций. Потребовалось около 1920 мс, чтобы закончить.

Затем я заменил его единственным System.Collections.Generics.Dictionary (Of String, String) (поскольку он хранит только строки) и с тем же объемом данных заняло всего около 5 мс. Разница огромная !!!

Упаковка и распаковка в этом случае - дорогостоящая операция.

Надеюсь, это ответит на ваш вопрос.

Приветствия из Аргентины!

PS. извините мой английский отстой!