Пользовательские индикаторы > Может общими усилиями ускорим расчет индикаторов?

[KotangenS]

Добрый вечер, форумчане.
Известно, что традиционный график в АД при навешивании на него индикаторов начинает страшно тормозить.
1.подтормаживание масштабирования графиков (УЖЕ ЗАГРУЖЕННЫХ)
2.дискретное отображение графика стакана (не плавно, а дискретно)
3.окна вызываются не всегда сразу (задержка 1-2сек)

Как пишут обладатели мощных процессоров (Ryzen 9 5950х, core i9-13900h) проблема железом не решается.
Да и как ей решиться? Макросом выяснил, что при каждом изменении графика (цены последней свечи), а также уменьшении или увеличении числа отображаемых свечей (т.е. при нажатии + или - на графике) происходит перерасчет значений индикаторов на всю длину истории. При этом глобальные переменные в индикаторе при каждом перерасчете индикатора обнуляются.
Мягко говоря такие расчеты излишни.
Соответственно возникла идея, в общем то я думаю не только у меня, а что если:
1) сохранять в файл значения индикатора для исторических баров, на которых индикатор уже был рассчитан и, например, подтягивать их из файла;
2) подтягивать из файла данные о последнем баре, на котором был рассчитан индикатор и если последний CurrentIndex не изменился, то не пересчитывать значения индикатора.
В таком случае мы не получаем данные индикатора на последней свече, до того момента пока она не закрылась. Зато индикатор не пересчитывается постоянно, а как только свеча закроется сразу получим данные значения индикатора,что по сути и нужно.
К сожалению знаний в программировании не хватает для реализации данного алгоритма.
Может кто-то уже сделал такое? Поделитесь пожалуйста.

[Mandarin84]

Всё верное написано. Проблема эта есть. Лично у меня уже года 3 и увы пока её никак не решили. Мучаемся и все тут

[BugsDigger]

Да, пересчеты - это кошмар. К медлительности добавляется то, что при перерасчете от начала начальный бар расчета дрейфует, что может дать другие показатели индикатора в конце (я условно называю такие индикаторы "неустойчивыми" в отличие от "устойчивых", которые в конце на достаточной истории нивелируют различие в начальных данных).

Cчет индикаторов с постоянной трудностью O(1) еще туда-сюда, но как только трудность повышается (даже O(N)), дело становится нехорошо, а с большей трудностью я вообще молчу. Это редко учитывают те, кто пишет код самостоятельно. (Кстати, надо как-то озаботиться и сделать индикаторы min/max в бегущем окне с постоянной трудностью, а то лобовая реализация в "системных" индикаторах тормозит безбожно).

Делать сохранение насчитанных данных в пользовательском коде - самоубийство, слишком громоздко и трудно поддерживать.
А надежды на то, что эту простейшую схему (тупой перерасчет) разработчики сменят на что-то более сложное, но более быстрое, у меня лично никакой.

[nikkrav]

.

[nikkrav]

Cчет индикаторов с постоянной трудностью O(1) еще туда-сюда, но как только трудность повышается (даже O(N)), дело становится нехорошо, а с большей трудностью я вообще молчу. Это редко учитывают те, кто пишет код самостоятельно. (Кстати, надо как-то озаботиться и сделать индикаторы min/max в бегущем окне с постоянной трудностью, а то лобовая реализация в "системных" индикаторах тормозит безбожно).

Приведите примеры таких индикаторов,
если не сложно.

[BugsDigger]

Ну, например, лобовое бегущее среднее (путем пересчета каждый раз среднего в окне) будет O(N), где N-длина окна.
Если же не в лоб, а путем использования для вычисления среднего суммы, полученной на первом шаге, вычитая на каждом следующем шаге первый элемент и добавляя последний, поимеем постоянную сложность O(1), т.е. не зависящую от длины окна N.

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

В основных "системных" индикаторах в основном код приведен к постоянной сложности, где возможно. А вот min/max в окне был "в лоб" и со сложностью O(N) (давно не смотрел, м.б. сделали уже, хотя вряд ли; кто-то недавно жаловался, что индикатор как раз с использованием min/max тормозил безбожно, думаю, что как раз из-за этого).

[ensh]

Да, были попытки....

Я даже назвал этот движок Alfa-Flow, ибо навеяло flow-архитектурой, получилась вычислительная сеть куда можно скармливать всякие тики из свечек, графиков и тд и тп, втаскивать расчеты индикаторов, устраивать мемоизацию, чтобы не пересчитывать по несколько раз, довел до пруфконцепта с графиком и новым движком который тоже был индикатором) но на перевод всего функционала нужны были челоеко-часы,а мне и так работы хватало...

Второй подход - отрефакторить существующую вычислительную и визуальную модель терминала, благо ее создатель уволился и переехал за границу...
В итоге, пришел к реактивной модели вычислений, с мемоизацией, новым архивом свечек, рефакторингом отображения, практически получилось, новый код уделывал старй по всем параметрам памяти, отзывчивости, быстродействию... заодно подшаманил графику чтобы не было утечек памяти... даже бету выложил, в управлении поддержка заметила, что все прям получше стало.... и никаких багов, их все устраиволо по функционалу. Опять же, реактивная модель, позволила бы развивать индикативный функционал более оптимально и естественно.
Короче, все взлетело, но несколько досадных багов в геомтрических фигурах, а может и не багов, просто фигуры стали получать нормальные данные...
В конце-концов, это можно было бы выложить в релиз и подшаманить по-ходу несколько вещей нечасто используемых, но никому это было не нужно и могучий, красивый и результативный месячный рефакторинг -похерили...
С тех времен, август 2018й, все встало и никто оптимизацией не занимался, а только наворачивали и накостыливали новый функционал, а я ушел из разработки, даже DevExpress с 16 версии (который я поднимал с 2016 и 2017м) не могут обновить до какого-нибудь актуального состояния...
Ну а теперь когда инсталлятор весит 300МБ вместо вычищенных мною 40Мб, а версия дот нета древняя 4.6 можно не надеятся

[ensh]

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

Это позволило бы распаралелить вычислительную нагрузку, отображение, облегчить обновление и тд и тп

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

У меня много хороших идей) но походу, техническое развитие остановили окончательно и будут доить, а меня по-сути единственного человека, который продвигал технические инновации слушали мало и сейчас не будут ни слушать не сотрудничать