Скоростная обработка тиков. Рекомендации

Последнее время приходится много работать с тиковыми данными и, естественно, приходится их обрабатывать в TSLab. Так как свечей много и в каждой свече еще больше тиков, то процесс обработки оных может занимать длительное время. Очень хочется чтобы работало все быстрее и как итог, было решено протестировать основные паттерны работы с тиками. В результате сделаем вывод о том, как реализуется скоростная обработка тиков чтобы было быстро и хорошо. И да, картинок не будет 🙂 .

Скоростная обработка тиков. Постановка задачи.

Схема обработки тиков весьма однообразна и содержит пару базовых паттернов.
— прямой обсчет тиков текущей свечи. Мы работаем прямо с тиками без создание промежуточных списков.
— обсчет тиков свечи через промежуточные коллекции и списки.

Вообще, вся схема обычно происходит путем перебора всех свечей начиная с первой и кончая последней. На каждом баре мы что-то вычисляем, и потом результат куда-то выдаем. В тестовом скрипте роль бара будет выполнять массив с числами double (якобы тики), а процесс перебора баров реализуем через простой цикл.

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

Для измерения времени работы, будет использовать специальный класс System.Diagnostics.Stopwatch. Он позволит измерить время с высоким уровнем точности. Каждый проход по свечам будем замерять как единую операцию. В итоге получим список измерений для разной длины массива тиков.

Обработка коллекций может происходить с использованием трех типичных инструментов:
— стандартные циклы (for, while, do)
— цикл foreach
— linq команды

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

Тестовый скрипт

Скрипт получился не очень большой но покрывающий все наши исходные задачи.

            // чтобы набор чисел всегда был одинаков, используем seed
            var rnd = new Random(100);
            
            // стартовый размер массива данных и делитель
            var arrSize = 100000000;
            var div = 1;

            var currSize = arrSize;
            while (currSize > 10)
            {
                div *= 10;
                currSize = arrSize / div;

                // якобы массив тиков
                var arr = new double[currSize];
                
                for (int i = 0; i < arr.Length; i++)
                    arr[i] = rnd.Next(1, 1000);

                var watch = new Stopwatch();
                watch.Start();
                var count = 0.0;

                // якобы перебор свечек  
                for (var i = 0; i < div; i++)
                {
                    count = 0;
                    // сюда будем вставлять команды работы с тиками
                }


                var msg = string.Format("ArrLength: {0}, Loop: {1}, Time: {2}, count: {3}", currSize, div, watch.Elapsed, count);
                Debug.WriteLine(msg);
            }

Прямой обсчет тиков

Прямой обсчет не использует промежуточных списков и массивов, а напрямую извлекает тики из массива тиков и производит арифметические операции. Примеры такой логики:
- подсчет числа сделок на покупку в свече.
- расчет объема свечи из тиковых сделок.
- подсчет объема всех покупок в свече.
- подсчет сделок больше заданного объема в свече.

В общем, примеры показывают направление нашей мысли. Для теста будем рассчитывать объем всех сделок с объемом больше 500. Максимальный объем тика у нас 1000, как следует из тестового скрипта.

Примеры кода для каждого варианта:

    // linq
    count = arr.Sum(v => v > 500 ? v: 0);

    // for
   for (int k = 0; k < arr.Length; k++)
       count += arr[k] > 500 ? arr[k] : 0;
   
    // foreach
    foreach (var item in arr)
        count += item > 500 ? item : 0;

Результаты следующие:

Как видно, linq остает почти в 3 раза от других вариантов цикла. При этом у linq какое-то неадекватное увеличение времени выполнения при размере массива 3. Это не ошибка, результат повторяется стабильно. Видимо накладные расходы на использование linq здесь вылезают по полной программе и время резко увеличивается. Так что, хоть и красиво и удобно, но для обработки тиков linq не подходит при прямой работе с тиками. Увы и ах.
for и foreach идут ноздря в ноздрю и между ними выбирать не стоит. Какой вариант удобнее такой и используйте, но если вы патологический кодер, то используйте всегда базовые циклы, ведь они немного быстрее 🙂 .

Обсчет тиков через промежуточные коллекции.

Данный паттерн встречается не менее часто чем предыдущий. Примеры реализации:
- график footprint который можно увидеть в TSLab
- неоднократное обращение к определенной выборке тиков, например к тикам покупок.
- любой другой случай где мы часть тиков помещаем в отдельную коллекцию.

Так как выше выяснили что foreach так же быстр как for, то не будем задействовать for в тестах.

Примеры кода для каждого варианта:

    // linq без конвертации в другой вид коллекции
    var result = arr.Where(v => v > 500);
    
    // linq с корвертацией в массив
    var result = arr.Where(v => v > 500).ToArray();

    // foreach с созданием отдельного списка
    var result = new List();
    foreach (var item in arr)
    {
        if (item > 500)
            result.Add(item);
    }

После получения коллекции, будем производить с ней какую либо операцию, например, подсчет объема тиков.

    // проводим операцию над коллекцией полученной выше одним из способов
    foreach (var item in result)
       count += item;

Результаты следующие:

Здесь, работа с linq себя неплохо зарекомендовала, но только если не переводить коллекцию в массив или список. Если будете конвертировать то сразу теряете в два раза производительность. Возможно, конвертация даст плюс если нужно много раз обратиться к коллекции, тогда мы избавимся от накладных расходов linq но получим замедление на создание массива. В общем – не лучший вариант.

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

Тяжело в учении – легко в бою

В завершение, хотелось проверить как будет работать скоростная обработка тиков в реальных условиях, то есть, в TSLab. Тиковых данных у меня достаточно, засим переходим в реальные полевые условия (можно накачать тики с http://ftp.moex.ru или достать где-то еще). Тестировать буду на простом примере из библиотеки индикаторов RusAlgo. По умолчанию, там используется linq в виду его красоты и удобства написания. Кубик расчета объема всех сделок на покупку и продажу, подойдет как нельзя кстати. Создадим новую версию кубика, с применением стандартных циклов и будем сравнивать скорость обработки всех баров. Для того чтобы время было ощутимое, в коде скрипта завернем цикл, в котором будем многократно повторять обсчет тиков, что даст нам более адекватные цифры для сравнения.

Важное замечание: нужно один раз прогнать скрипт, чтобы тики подрузились с диска, тогда время обсчета будет зависеть только от скорости скрипта, а не от скорости вашего диска.

Приводить код тестового скрипта не буду, сразу переходим к итогам:

Как видим, linq оказался в 2 раза тормознее (ну не совсем в 2, но разница серьезная). Ранее, мы получали еще большую разницу. Почему? Очевидно, что работа с объектами сделок и запрос свойств объектов, дает затраты и эти затраты одинаковы в обоих случаях, но сильно влияют на общую скорость работы.

Давайте для окончательной проверки, возьмем кубик суммирующий объемы всех сделок на покупку/продажу. Его особенность в том, что linq используется правильно, а именно в виде связки

value = trades.Where(trd => trd.Direction == Direction).Sum(trd => trd.Quantity);

Такая связка позволяет избежать создания промежуточных списков и отработать достаточно быстро и удобно.
Посмотрим что у нас получится для обоих вариантов:

Разрыв стал меньше, но все равно существенный. Если скрипт работает 17 минут вместо 24-х, это заметно.

Выводы

Статья была написана не с целью написания, а в процессе проведения тестов и оптимизации своих кодов работы с тиками. Это отразилось и на сборке индикаторов RusAlgo, в виде ускорения работы некоторых индикаторов. Ну, и память не вечна, лучше всегда иметь шпаргалку на будущее 🙂 .

Собственно итоги в куче:
- Везде где можно используем стандартные циклы (for,while,do) или foreach. Ускорение до двух раз.
- Если нужна промежуточная коллекция, лучше создать ее в виде списка или массива чем использовать linq. Памяти сожрет больше, скорость будет тоже больше. Ускорение небольшое, но есть, особенно если запрос к коллекции будет не один а много.
- Скоростная обработка тиков это не миф, а реальность 🙂 .

PS: Всем добра. И не стоит заниматься оптимизацией скорости, если не возникла проблема выполнения скриптов в течение минут десяти и более 🙂 .

Родион Скуратовский - ra81

Вы уже сейчас можете записаться на Видео курс и научиться самому делать зарабатывающих торговых роботов!

Можно записаться на следующий поток ОнЛайн курса, информацию по которому можно посмотреть тут:

Если же вам не хочется тратить время на обучение, то вы просто можете выбрать уже готовые роботы из тех, что представлены у нас!

Также можете посмотреть совершенно бесплатные наработки для МТ4, Квика, МТ5. Данный раздел также постоянно пополняется.

Не откладывайте свой шанс заработать на бирже уже сегодня!