MT5 и скорость в боевом исполнении - страница 70

 
Большая просьба добавить нужный функционал.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Новая версия платформы MetaTrader 5 build 2650: Фоновая загрузка графиков и улучшения в профилировщике MQL5-кода

fxsaber, 2020.11.04 16:50

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

И прекратить вывод данных в окно Обзор рынка и другие, когда окно Терминала не видно. Например, когда текущее приложение (например, браузер) находится в состоянии активного и maximized.


Бородатая нужда - определение, какой чарт сейчас выбран. Люди вынуждены использовать костыльные WinAPI-решения.

Активный график (ID активного графика)
Активный график (ID активного графика)
  • 2014.10.20
  • www.mql5.com
Доброго времени суток! Нужно элементарно определить ID активного графика (того что выбран в данный момент...
 

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

Многократно объясняли, почему.

Гарантированных нулевых задержек у потоков выполнения не может быть в рамках текущих (всех) процессорных архитектур. Рассказы про "операционки системы реального времени" остаются мифами, можно их не упоминать.

 
fxsaber:

С одиночными выбросами понятно, спасибо за подробные объяснения. В данный момент все же обсуждаем не SymbolInfoTick, а лаги другого характера, которые сыпятся почти на каждом тике.

Речь только о ваших одиночных замерах выбросов - они больше не принимаются и не рассматриваются. Весь ваш анализ был построен исключительно на выбросах.

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

 
Renat Fatkhullin:

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

Здесь по ссылкам подробности, включая комментарии в исходном коде.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

MT5 и скорость в боевом исполнении

fxsaber, 2020.11.05 07:42

Кто использует VPS от MQ, просьба поделиться результатом работы там следующих программ.

  1. Советник, который ловит лаги OnTick/OnBook.
  2. Советник, который ловит тики со старым временем.
  3. Скрипт, который замеряет среднее время выполнения Sleep(1).
 

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

это так, к слову, без камней ни в чей огород

 

Раз неизбежно возникают одиночные выбросы, то логично иметь штатные функции, которые возвращают массив всего Обзора рынка и массив всех текущих позиций/ордеров. По аналогии MarketBookGet.

Сейчас циклами приходится бегать. Это ОЧЕНЬ дорого.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

MT5 и скорость в боевом исполнении

fxsaber, 2020.10.07 12:41

Практическая нужда заставляет так писать.

// Возвращает время Обзора рынка в миллисекундах.
long TimeCurrentMsc()
{
  long Res = 0;
  
  MqlTick Tick;
  
  for (int i = SymbolsTotal(true); i >= 0; i--) 
  {
    const string Symb = SymbolName(i, true);
    
    if (SymbolInfoTick(Symb, Tick) && (Tick.time_msc > Res))
      Res = Tick.time_msc;
  }

  return(Res);
}

ЗЫ TimeCurrentMsc почему-то не вводится в MQL5, несмотря на неоднократные просьбы.

 
Slava:

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

Гонки за ресурсы? Бесконтрольное создание новых потоков? Конфликты на ровном месте?

Хотите необъяснимых тормозов?

В событийной модели все события всегда ходили строем, по очереди. Жёвано - пережёвано.

Ни какого ускорения обработки событий, в асинхронной архитектуре? Вы серьёзно?
Ускорение обработки пользовательских програм, а конкретнее их обработчиков. Об этом речь.

Я понимаю что вы стараетесь минимизировать использование потоков. Но как один из вариантов, каждый обработчик запускать в отдельном потоке.
Не какого бесконтрольного создания потоков. В пользовательской программе всего несколько обработчиков, их и запускать каждый в своём потоке при старте программы.
А мютексами или чем там вы синхронизируете, уже синхронизировать события между обработчиками.

Но если для вас потоки это боль, то как вы упомянули есть событийная модель, которая позволяет работать в одном потоке. Обработка событий, в цикле событий с запуском задач. 
Цикл событий хоть и крутится последовательно, но задачи этого цикла обрабатываются паралельно!
Об этом и речь, все обработчики в программе выполнять в этом цикле событий, тогда все события будут асинхронны и поступать одновременно в реалтайме.
То есть одинаковые события в OnTrade и OnBook будут соответствовать. 
Ну поинтересуйтесь уже как работает event loop в других языках.
Если event loop уже есть в терминале, то просто примените его к обработчикам в программах. Вот и всё.
 
Roman:
каждый обработчик запускать в отдельном потоке.

Нафиг такое. MQL-программы станут сложнее на порядок, если из разных потоков будет read\write доступ к внутренним переменным, например.

 
fxsaber:

Нафиг такое. MQL-программы станут сложнее на порядок, если из разных потоков будет read\write доступ к внутренним переменным, например.

MQL-программы сложнее не станут, это просто головняк синхронизации для разработчиков. Который естественно нет желания решать.
Или тупиковая начальная архитектура проекта, не рассчитанная под данную модель.
А переписывать проект под новую модель, естественно не кто не будет. 
Событийная модель event loop, для обработчиков лучше подходит. Это и пытаюсь донести.
И эта модель скорее всего давно уже есть в терминале, просто не применена к обработчикам.

 
Roman:

MQL-программы сложнее не станут...

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

Причина обращения: