~/topic/11936/problemy-s-proizvoditelnostyu-v-metode-connector_getsecurity()/ Copyright @ StockSharp Platform LLC 2010 - 2025 2026-04-29T23:06:32Z https://stocksharp.com/images/logo.png https://stocksharp.com/posts/m/50660/ 2020-06-10T17:49:25Z 2020-06-10T17:49:25Z Alexander https://stocksharp.com/users/99075/ info@stocksharp.com Спасибо за фикс. Однако, если я правильно понимаю, проблема все еще сохранилась (хоть и в более мягком виде) в случае использования HistoryEmulationConnector, т.к. он использует CollectionSecurityProvider, в котором метод LookupById() использует перебор коллекции. В случае одновременного тестирования на истории нескольких инструментов это все так же будет приводить к перебору коллекции инструментов на каждом входящем тике. Это будет работать существенно медленнее, чем было раньше.<br /> Copyright @ StockSharp Platform LLC 2010 - 2025 https://stocksharp.com/posts/m/50652/ 2020-06-09T19:05:29Z 2020-06-09T19:05:29Z Alexander https://stocksharp.com/users/99075/ info@stocksharp.com В последних коммитах была внесена серьезная проблема с производительностью в методе Connector.GetSecurity(). Ранее там использовался entityCache, который позволял быстро получить Security по идентификатору. Теперь там идет использование цепочки методов: TraderHelper.GetOrCreate() -&gt; TraderHelper.LookupById() -&gt; InMemorySecurityStorage.Lookup() -&gt; TraderHelper.Filter() -&gt; Messages.Extensions.Filter()<br /><br />Метод TraderHelper.LookupById() хоть и должен вернуть только один единственный объект, вызывает все равно метод InMemorySecurityStorage.Lookup(), который работает с коллекцией Security.<br />Метод InMemorySecurityStorage.Lookup() является более универсальным и работает с коллекцией, он всегда вынужден перебирать коллекцию, проверяя критерий на каждом Security. Он вызывает метод TraderHelper.Filter() на всей коллекции сохраненных Security.<br />Метод TraderHelper.Filter() вызывает сначала преобразование коллекции securities в Dictionary с ключами типа SecurityMessage, что вызывает перебор всей коллекции с достаточно тяжелым кодом конверсии Security -&gt; SecurityMessage, а затем вызывает на ключах этого словаря метод Messages.Extensions.Filter().<br />Метод Messages.Extensions.Filter() снова перебирает всю коллекцию, но на этот раз сообщений SecurityMessage, только что созданных из Security.<br /><br />Изначальный метод Connector.GetSecurity() вызывается на каждом входящем сообщении из коннектора.<br /><br />Таким образом имеем следующее.<br />Допустим, что у нас есть очередь из 1000000 входящих сообщений (загрузка тиковой истории) и всего в коннектор загружено у нас 100 инструментов. На каждом входящем сообщении мы имеем два перебора коллекции securities с достаточно тяжелым кодом, выполняющемся на каждом переборе, т.е. у нас получается 1000000 * 200 переборов элементов securities. Каждый перебор - это достаточно тяжелый код по созданию словаря и конверсии всех элементов, а также по вызову сборки мусора, т.к. создется очень много временных объектов нулевого поколения. Чем больше занружено инструментов, тем медленнее (мультипликативно!) это будет работать. ВременнАя сложность текущего кода получается: 1000000 * 200 * X, где X - время, которое тратится на один элемент.<br /><br />Совершенно очевидно, что это должно работать с константной сложностью с использованием кэша, как и было ранее. ВременнА сложность такого кода будет 1000000 * Y, где Y - это очень маленькое константное время выборки из кэша. Величина Y много меньше, чем X. По опыту могу казать, что разница тут будет в разы.<br /><br />Т.е. текущий код работает минимум в 200 раз медленнее, но более вероятно, что где-то в 1000-2000 раз медленнее, чем должен, на 100 инструментах. При этом чем больше инструментов будет, тем более медленно он будет работать, т.е. имеем полиномиальную сложность времени исполнения.<br /><br />Если мой анализ не убедил, то просто попробуйте заказать тики с начала сессии в квике, запустив код где-то в конце дня, чтобы накопилось достаточное количество тиков, и увидите все это в динамике.<br /> Copyright @ StockSharp Platform LLC 2010 - 2025