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. Также можно ускорить процесс, если во время инициализации определить размер массивов. Код и замеры не буду писать. Отмечу только, что скорость значительно выше. Проводите эксперименты!!!
Оригинал.
НоваБев - без изменений
Давно не было постов про Белугу, и без внимания оставлен пресс-релиз за 1-ый квартал, потому что существенных изменений в прогнозы это не внесло. Белуга в своих пресс-релиза...
khornickjaadle, юрики с таким же успехом накануне много лонгов скинули,
сегодня их снова купили, только дороже, что интересно — нефть не реагировала
на цифры о скважинах, если бы это были реа...
Дмитрий C основной, достаточно, что ранее бумага стоила гораздо дороже, тут до хаев ещё 20-30 планок надо сделать.
Ныне КС+5%, для эмитента с рейтингом ВВ, маловат. Надо бы КС+5,5%, или даже КС+6%.
Ну обосрался разок по-крупному, чего так армагедонить? На крайняк инвест программу зарежут, персонал децимируют, долю кого нибудь получит в подарок, вот и вышли в плюс
На графике видно, отработана фигура похожая на ГиП ,(локальный разворот), увеличу позицию на 195 если на дневном графике отработает фигура похожая на перевернутую ГиП,
примерная цель 300
вечерний репост
Уехавшие за границу украинцы опасаются усиления мобилизации в стране — Washington Post
Живущие в Европе украинцы недовольны новым законом об усилении мобилизации на Украине,...
Chef, крохи конечно
цель 120 до конца года, так вижу ситуацию
23:43
до 2026 года газпром выгодней купить) тут риск огромный и ни какой страховки, так как контора частная, а если долг не погасят, компания потеряет ~50% активов, активы могут продать
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, если Вы можете сделать изначально красиво, и знаете как, то Вы господь бог… Суть в том, что оптимизировать нужно только то, что на самом деле имеет смысл оптимизировать. Это и выясняется при помощи профайлера.
В вообще, то, что описал топик-стартер в технологии программирования называется «преждевременной оптимизацией»…
Основная цель была именно эта!
Наполнить комментариями.
Я всё же не дал вчера сгинуть посту в пучину.
Простейший алгоритм запрогить в ниньзе.
Сравнить просто с иными средами/терминалами.
Буду благодарен.
(в личку всё)