Кое что про скорость.
Краткие тезисы, можно сказать самому-себе напоминалка
Подобные тезисы уже были озвучены, а это можно сказать обобщение "по вновь открывшимся обстоятельствам" :-)
- в любом софте кол-во обращений к SymbolInfo и прочим глобальным справочникам должно быть сведено к минимуму. Советник или индикатор должен сам помнить все необходимые данные.
Потому-что в худшем случае обращение к справочнику занимает 15-16 msc, когда неудачно попали на его обновления. На таком фоне потуги оптимизаций просто лишняя суется и тлен.
- внутри OnTick, OnCalculate, OnBook лучше ничего не рисовать. Не обращаться к объектам чарта, их свойствам и самому чарту. Многие функции там синхронные и могут долго исполняться.
Хотя разработчики уверяют что ChartRedraw просто ставит флажок "надо потом перерисовать", сдаётся что это немного не так. Если много заявок в очереди (ObjectCreate,ObjectSet..) или от внутренних условий/таймеров, перерисовка включится прямо сразу и будет пенальти по времени.
К тому-же в прогонах тестера и оптимизаторы всё равно функций рисования нет, заглушки и эмуляция. Хоть и заглушки, всё равно какое-то время жрут. Убрать к чёрту рисовку - будет тестироваться чуть быстрее.
Внутри OnTick советников тормозить нельзя никоим образом - малейшее замедление это проскальзывание,ошибки исполнения и пропуск следующих тиков.
С OnCalculate индикаторов примерно то-же и даже хуже, все индикаторы чарта исполняются в одном потоке, один за другим. Если каждый немножко "задумается" то весь чарт будет замирать
Тики и книга могут прилетать очень часто и рисовать с таким темпом даже и смысла нет. К примеру, Binance выдаёт до 20000 трейдов в минуту:
каждый трейд, это можно считать что тик. Каждый последующий почти всегда по другой цене, да тик.
даже учитывая что OnTick OnСalсulate вызываются не на каждый, а сразу на пачку и по мере возможности, всё равно это сумасшедший темп.
На привычном форекс, когда с другой стороны сервер MQ или иной, сервер агрегирует и разрежает потоки, чтобы и сеть посвободнее и терминалы успевали.
Получаются довольно "тепличные" условия по темпам.
Но такая лафа не навсегда - если MQ серьёзно настроены войти за границы валютного форекс, требования к скоростям и времени выполнения OnTick,OnCalculate резко вырастут.
- основная отрисовка соответственно переезжает в OnTimer, больше её поместить некуда. Как в Game-Dev: когда время рендерить очередной фрейм, смотрим внутренние флаги что поменялось, что требуется обновить и только то и выводим.
- вообще в OnTimer очень непростой шедулинг - там и рисования и суб-таймеры и отложенные действия и львиная часть рассчётов.
- единственное место где рисовать приходиться - в OnChartEvent, это условия комфорта пользователя.
- маленький злобный нюанс - отслеживать геометрию экрана, масштаб и прокрутку чарта тоже приходится в OnTimer - соотв.им CHARTEVENT приходит с раздражающим лагом. Так-же и с мышью.
- Помимо рисования и интерактива с пользователем софт много чего делает - всякие рассчёты в первую очередь, пишет файлы, отчёты.
В рассчёты надо упарываться, оптимизировать, приводить к инкрементной форме, использовать ONNX.
Если нечто заведомо долго считать, а 5-10 сек это уже очень-очень долго, - то выносить наружу. Варианты:
* разбивать на отдельные шаги и считать в таймере.
* в Питон. Но модель MetaTrader <-> подразумевает что командует питон, обратное сложно
* В R. Интерфейс немного заброшен, возможно нестабилен, но использовать разумно - держим терминальное соединение, R работает в отдельном процессе, но командуем мы.
* запускать доп.советник на пустынном чарте и взаимодействовать с ним. Заодно и часть GUI (таблицы/отчёты/настройки) можно в него убрать - там уже нет жёстких требований таймингов
* записать задачу в файл или SQLite, внешняя программа её обсчитает и подобным образом ответит
* веб-реквест локальной службе. Например к RedisAI.
* с ATcl для подобных вещей я thread pool использую.
любой вариант имеет достоинства и недостатки, универсального нет.
- файлы и базы тоже могут тормозить. Поэтому RAM-диск наше всё. Оперативную часть баз, рабочие часто записываемые файлы и прочее подобное, только туда. Делается RAM-диск, на него или его каталог ссылку из Files или Common
- оповещения. Как ни странно, но самое быстрое и удобное оповещение это Mail :-) Поднять простой SMTP сервер-пересыльщик или наскриптовать на знакомом языке (python, nodejs) скрипт который принимает входящую почту. В настойках терминала ставится только localhost и всё работает моментально.
