23 марта 2017, 00:26
Производительность роботов на C# (NinjaTrader).
Производительность роботов на C# (NinjaTrader).
Перед тем, как использовать в своем роботе переменные типа Dictionary или List, если у вас производится частое обращение к ним, обязательно проведите анализ на производительность. Вот мой кусочек анализа.
Для примера описываем переменные:
private List<KeyValuePair<int, string>> listArray; private Dictionary<int, string> dictArray;
По сути будем иметь набор связок Integer и String. Содержание в данном случае не особо важно. Важно то, что это содержание одинаково в обеих переменных.
А теперь просто заполним эти переменные одинаковыми записями:
// Переменные для замера времени выполнения
sw1 = new Stopwatch();
sw2 = new Stopwatch();
// Инициализация переменных
listArray = new List<KeyValuePair<int, string>>();
dictArray = new Dictionary<int, string>();
// Стартуем замер производительности
sw1.Start();
for (int i = 0; i < 1000000; i++)
{
//Добавляем переменную в массив
listArray.Add(new KeyValuePair<int, string>(i, "test"));
}
// Останавливаем замер производительности
sw1.Stop();
// Выводим результат
Print("List: " + sw1.ElapsedMilliseconds);
// Очищаем список
listArray.Clear();
// Стартуем второй счетчик производительности
sw2.Start();
// Запускаем второй цикл
for (int i = 0; i < 1000000; i++)
{
dictArray.Add(i, "test");
}
// Останавливаем счетчик
sw2.Stop();
// Выводим результат
Print("Dictionary: " + sw2.ElapsedMilliseconds);
А вот результат:
List: 33 Dictionary: 73
Я исследовал данный вопрос для своей задачи. Перед применением, обратите внимание на плюсы и минусы относительно ваших целей. Например я читал, что Dictionary медленно добавляет записи, но зато довольно быстро обрабатывает их (поиск, например).
P.S. Также можно ускорить процесс, если во время инициализации определить размер массивов. Код и замеры не буду писать. Отмечу только, что скорость значительно выше. Проводите эксперименты!!!
Оригинал.
botlib, ты про эти облигации?
Кредитный рейтинг: А- (АКРА)
Ориентировочная ставка купона: фиксированная с дополнительным доходом, по 1-12 купонам – не выше 15%, по 13-24 купонам – 14%, по 25-36...
Heinrich von Baur, нету у меня Яндекса, я просто выбираю акции, захожу на ветку чего-нибудь интересного почитать, а тут два болвана ты и заяц какой-то бред про капу 10 трлн пишут, ещё и агрызаются,...
Саня 57, к сберовским 95, видимо, опаздать боится…
Получилась какая то Хрень, если честно. Хотя до сих пор вроде в плюсе. Часть акций зафиксил. Вводные покупка средняя 4400р за день до допки. Продал 1/8 в первый день начала торгов после допки по 1600-...
По ситуации на рынке и ММВБ проведенно экстренное совещание братства СМАРТЛАБА, было принята следующая резолюция:
1. Покупать в лонг от 218 СБЕР, продавать в шорт от 216 Сбер,
2. Синим пингвинам н...
16:38
налетай в шорт
16:45
Правда или обман с расчетом доходности фьючерса IMOEXF терминале Т-банка. Рассудите, пол дня им доказываю что такого быть не может:
Фьючерс #IMOEXF
16.12.204 в 16:24 продажа 5 контактов по 2448...
Наталья, Сегодня
Минфин признал аукцион по размещению ОФЗ выпуска 26246 несостоявшимся «Министерство финансов Российской Федерации сообщает, что аукцион по размещению облигаций федерального займа с постоянным купонным...
HFT?
Или ещё что-то?
И для теста будущего по случайным?
Странный совет!
Код не разбирал, потому что изначально прочитал пост и в комментариях указал про ОБЯЗАТЕЛЬНОСТЬ.
Пойдем с основ?
Есть 2,5 вида ограничений:
1. ФП не позволит
2. Программа (и т.п.) не позволит.
Что далее?
Далее уже тут начинаешь изначально писать то, что будет позволять.
Плохо, когда программист не знает того, какие ограничения в платформе/языке/приложении/программе (уж в железе он знает).
Тут скорее балансировка между максимальной масштабируемостью (абстракции, шаблоны, коллекции) и скоростью. Если бы автор топика решил добавить в обзор ещё и работу с простым массивом, то очень бы удивился росту скорости по сравнению с тем же List'ом.
Как минимум про целевую аудиторию, плюс про то, что массив задать, о котором сказано в самом конце.
Если это для практиков под нинзю — то есть куча ресурсов, где это просто необсуждаемо и аксиома.
Если это для сЛаба — то надо бы и уточнить/ответить.
ПОСТ относится к бэктесту!
об этом нет ни одного упоминания напрямую!
Я об этом изначально и писал.
Железо/софт/разум.
1. Все зависит от конкретной задачи. Если все время писать в коллекцию и редко читать, то List<T>, если все же читать, то конечно Dictionary<T>
2. У List<T> нет реализации ConcurrentList<T>, во всяком случае в 4.0, а ConcurrentDictionary<T> — существует.
3. С Arrays при неаккуратном обращении возникает boxing/unboxing
Dzam, а как же HashSet или LinkedList? ;-)
Зная заранее данные железа+софта+мануал, Вы изначально построите код так, чтобы избежать ограничений из Вашей эмпирики.
Занятно, что Вы предупреждаете остальных.
Однако, нет ответа на мой начальный вопрос: какова целевая аудитория, что даже Т.М, отметку в плюс поставил, хотя в своей жизни просто формулу параболы с дискриминантом не запрогил!??????7
(ХеллоВорлд н даже и не писал в коде — это слишком банально для гения)
Более того, я вообще не программист по образования.
И ещё более мне пофиг, но я тут откликнулся, чтобы пост автора стал более информативным.
Для того и задавал волпросы в комментариях, кое-где своё писал.
Дайте задачу, я её начну решать с того, сколько у меня ресурсов и времени.
А не просто начать, а потом столкнуться.
Программировать я начал для себя примерно 28 лет назад!
Потому и первый же мой коммент в теме сознательный.
Хотя проще было сразу оговориться, что про «бэктесты» и моделирование идёт речь в посте!!!!!!!!!!1
Ранее было от меня про то, что нужно знать ограничения. Если их нет (только ФП) — тонет вопросов.
С тех пор так и живем, если у Вас в коллекции 100-1000 да даже 10000 элементов, то и заморачиваться не стоит, ничего Вы не выиграете, используйте то, что удобно…
Кстати по моим тестам замена класса на структуру в таких задачах скорость больше чем в два раза увеличивала…
Да еще ищем места, где принудительно мусор собираем..., например если 20 млн… с диска грузанули, то временный список чистим, а потом гарбаж…
я честно комментариями пытался поправить пост, nj,.s он был понятен не только для «посвещенных»,
Первый же вопрос был про целевую аудиторию.
Надо так и писать сразу про «бэктест». ПРЯМО в заголовке или первых строках поста!
Я разгонял тему, чтобы она НЕ СГИНУЛА В ПУЧИНЕ г*внопостов!
Тема реальная!
Тема жизненная.
Тема узкоспециализированная.
Я своим опытом попытался помочь автору РАСШИРИТЬ и УТОЧНИТЬ.
Рад, что за сутки тема не сгинула, а даже новый вздох приобрела!
какое отношение реализация базовых структур данных иммет к скорости работы торгового терминала?
Тимофей ты начал копирайтеров нанимать чтобы контент генерировали из ничего?
тайтл поста не имеет ничего общего со статьей, чистый click bait
Автор в посте не конкретизирует задачу, приводя просто тесты его. и те с оговоркой «а больше не расскажу/».
OnBarUpdate при этом просто будет вызвать рассчет воркера и дожидаться результатов не будет, тем самым не блокируя работу. Что и есть асинхронный режим
ИЗНАЧАЛЬНО я и просил автора конкретизировать ЦЕЛЬ поста.
Dictionary — это хэштаблица. И подходит для работы с типами данных малой величины и на не больших объемах, потому что показатель производительности всегда константен.
Так приходится ковырять каждый контейнер под свои задачи. boost вон тоже наделал контейнеров, а там большая часть для обычных задач не подходит по производительности.
Если делаете фикс под срочку, пробуйте еще твайм. Он бинарный, сообщения формируются быстрее. Объем данных меньше и тд.
Учитывая что все данные вроде как сортированы по времени, то везде можно и обычный массив использовать, если память позволяет. в любом случае доступ линейный.
Другое дело соответсвие «тикер: набор данных» может вполне быть помещен в какой нить контейнер, так как врядли одновременно надо будет работать с десятками тысяч записей.
— для бэктеста время по большому не так важно, а значит можно делать как удобнее.
— для инициализации данных, для расчета чего либо перед стартом алгоритма? тут уже может быть более важно, возможно даже это самый вероятный случай когда оптимизация по записи и чтению может понадобиться.
-Для торговли, нам вроде как нужны лишь текущие данные, а значит доступ может быть прямо к обьекту структуры, ну или опять же таки через key:value если много разных тикеров.
В общем то хотелось бы действительно узнать в каких ситуациях стоит пренебречь удобством, ради выигрыша времени?
Я скорее абстракно размышляю, не про нинзю в данном случае, я ее не пользую. У меня интерес скорее личный, для своей системы :)
я так понимаю вы складываете обьемы там? как вариант хранить в памяти сумму последних 14 тиков, и значение первого тика, потом при каждом апдейте берете сумму — первый тик + последний и у вас новое значение. но это так на вскидку. :)
Но там же люди вроде нинзю трейдер юзают.
Андрей К, У Нинзи нет, но у Visual Studio есть. Правда в случае с Нинзей им не получается воспользоваться.
Denis, если Вы можете сделать изначально красиво, и знаете как, то Вы господь бог… Суть в том, что оптимизировать нужно только то, что на самом деле имеет смысл оптимизировать. Это и выясняется при помощи профайлера.
В вообще, то, что описал топик-стартер в технологии программирования называется «преждевременной оптимизацией»…
Основная цель была именно эта!
Наполнить комментариями.
Я всё же не дал вчера сгинуть посту в пучину.
Простейший алгоритм запрогить в ниньзе.
Сравнить просто с иными средами/терминалами.
Буду благодарен.
(в личку всё)