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

Новый комментарий
 
я так понял - от оборудования всё зависит 
 
Alexsandr San:
я так понял - от оборудования всё зависит 

Ничего подобного!

2020.05.29 15:08:44.938 Terminal        Windows 7 Service Pack 1 build 7601, Intel Core i7-6850K  @ 3.60GHz, 23 / 31 Gb memory, 43 / 226 Gb disk, IE 11, UAC, Admin, GMT+3
 
Alexsandr San:
я так понял - от оборудования всё зависит 

А я так думаю - нет )))

И даже не от загруженности компа...

 
prostotrader:

Ничего подобного!

да! у Вас аппарат и у предыдущего - результат разные - значит я не прав,не от мощности значит 

 
Aleksey Mavrin:

Что такое ОнМайн?  Как в очереди в онмайне может оказаться больше одного события, если каждое событие вызывает онмайн для обработки очереди?

OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию "Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди". Это другой подход к самим вычислениям

 
A100:

OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию "Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди". Это другой подход к самим вычислениям

Так, на всякий случай, ОнМэйн...

:) ;)
 
fxsaber:


В боевых советниках везде в подозрительных местах облачил функции в _B(FuncName(...), AlertTime). Вот короткая выдержка лога из самых свежих записей.

Столбец времени показывает, как часто случаются фризы.

Вы подменяете понятия.

Вот ваше исходное заявление:

К огромному сожалению, такой вызов HistorySelect длится 5-30 миллисекунд (самостоятельно замерял в Release-EX5). Когда в советнике в OnTick делается несколько подобных актуализаций (по-хорошему, нужно делать после любой паузы. Например, после каждого OrderSend.), то все становится безумно дорогим/долгим. HistorySelect может суммарно в одном OnTick съедать несколько секунд.

Даже в вашем терминале среднее время в 0.2 мс на один вызов ощутимо меньше указанных в исходном утверждении величин.

Теперь вы утверждаете, что иногда время выполнения функции может быть ощутимо дольше среднего. Это другой вопрос.

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

Предложеное решение через добавление функций HistoryDealsSelect() и HistoryOrdersSelect() в этом смысле абсолютно ничего не меняет.

Скрипт для проверки максимального и среднего времени:

void OnStart()
  {
   MqlTick Tick;
   SymbolInfoTick(_Symbol, Tick);
//---
   ulong start,end,max_time=0,avr_time=0;
   int   count=100000;
   for(int i=0; i<count; i++)
     {
      start=GetMicrosecondCount();
      HistorySelect(Tick.time, INT_MAX);
      end=GetMicrosecondCount()-start;
      //--- >1 ms
      if(end>1000)
         Print(" > 1 ms for one HistorySelect: ",DoubleToString(end/1000.0,2)," ms");
      //---
      if(end>max_time)
         max_time=end;
      avr_time+=end;
     }
   Print("Last tick time. Selected orders: ",HistoryOrdersTotal(),"; max time: ",DoubleToString(max_time/1000.0,3)," ms; avr time: ",DoubleToString(avr_time/1000.0/count,3)," ms; ",count," iterations");
//---
   Tick.time=(Tick.time/86400)*86400;
   max_time=0;
   for(int i=0; i<count; i++)
     {
      start=GetMicrosecondCount();
      HistorySelect(Tick.time, INT_MAX);
      end=GetMicrosecondCount()-start;
      //--- >1 ms
      if(end>1000)
         Print(" > 1 ms for one last day HistorySelect: ",DoubleToString(end/1000.0,2)," ms");
      //---
      if(end>max_time)
         max_time=end;
      avr_time+=end;
     }
   Print("Last day. Selected orders: ",HistoryOrdersTotal(),"; max time: ",DoubleToString(max_time/1000.0,3)," ms; avr time: ",DoubleToString(avr_time/1000.0/count,3)," ms; ",count," iterations");
//---
   HistorySelect(0, INT_MAX);
   Print("Orders total: ",HistoryOrdersTotal());
  }
2020.05.29 17:22:04.195 TestHistorySelect (EURJPY,H1)   Last tick time. Selected orders: 0; max time: 0.034 ms; avr time: 0.001 ms; 100000 iterations
2020.05.29 17:22:06.771 TestHistorySelect (EURJPY,H1)   Last day. Selected orders: 141; max time: 0.101 ms; avr time: 0.027 ms; 100000 iterations
2020.05.29 17:22:08.039 TestHistorySelect (EURJPY,H1)   Orders total: 31448
 
Anton:

Скрипт для проверки максимального и среднего времени:

Не буду комментировать Ваше мнение до процитированного. Вот результат запуска Вашего скрипта.

Точнее, я не смог дождаться его конца, поэтому заменил количество итераций со 100K на 1К.

        Last tick time. Selected orders: 0; max time: 3.880 ms; avr time: 1.315 ms; 1000 iterations
        Last day. Selected orders: 2061; max time: 7.131 ms; avr time: 4.309 ms; 1000 iterations
        Orders total: 50113

Разве это тянет даже на оценку удовлетворительно?

Вы посмотрите всю абсурдность ситуации. Чтобы тупо узнать количество сделок, нужно вызывать HistorySelect! Это, мягко говоря, не рационально.


ЗЫ На каждом тике в лучшем случае трачу суммарно десятки миллисекунд только из-за HistorySelect.

 
A100:

В самом простейшем виде:

Просто нужно изменить подход к самим вычислениям (делайте промежуточный return так часто как это требует задача). Но если это сложно, то считайте на 1ом этапе, что OnMain для Вас как бы и нет (Вы же основной код переносите не в OnMain, а в OnTrade2XX) соответственно в OnMain не нужно ничего узнавать

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


Вы делаете OrderSend. Если СРАЗУ после окончания OrderSend определенная позиция не закрылась по тейку, то делаете еще один OrderSend. Это вся логика, которую надо запрограммировать. Async не используем.


Теперь ситуация, которая произошла для нашего робота. Вы отправили OrderSend, и пока он выполнялся произошло срабатывание лимитника и после этого срабатывание тейка нашей позиции, что упоминал выше.


Какая реализация робота схематично? Не знаю, как реализовать это без тормозной HistorySelect или костыля OnTradeTransaction-шпиона, который дает доступ в любом месте кода ко всей истории транзакций. Если бы был реализован механизм доступа к очереди событий, то пример выше решался бы элементарно.


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

 
A100:

OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию " Во время выполнения OnMain-функции нет возможности узнать  состояние текущей реальной очереди". Это другой подход к самим вычислениям

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

При текущей структуре вами предложенную схему невозможно реализовать.

1234567891011...94
Новый комментарий