Ошибки, баги, вопросы - страница 2744

 
Aliaksandr Hryshyn:

Ошибка:


Спасибо за сообщение.
Исправлено.

 
Ilyas:

Вопрос по оптимизации. В Тестере на каждом тике нужно получить тик для дальнейшей работы. Делаю это так.

void OnTick()
{
  static MqlTick Tick;
  
  if (SymbolInfoTick(_Symbol, Tick))
    // ...
}


Понятно, что этот вариант будет медленнее:

void OnTick()
{
  MqlTick Tick;
  
  if (SymbolInfoTick(Symbol(), Tick))
    // ...
}


Но еще тормозит SymbolInfoTick, потому что string-параметр передается не по ссылке.


Возможно ли иметь штатные SymbolInfo*-перегрузки, где string передается по ссылке?


А лучше, конечно, иметь

const MqlTick _Tick; // Текущий _Symbol-тик.


В Оптимизаторе эти функции вызываются десятки миллиардов раз.

 
Ilyas:
Вы предлагаете добавить функцию GetNextEvent ?

Не совсем, скорее бы назвал данную функцию как HandleNextEvent, возможная сигнатура:

bool HandleNextEvent (ENUM_EVENT_TYPE);


При вызове, аналогично GetNextEvent, проверяет наличие указанного ENUM_EVENT_TYPE в очереди,
и при наличии данного события, автоматически передает управление на пользовательский код соответствующего обработчика (OnChartEvent, OnTrade, OnTradeTransaction, ... (спасибо fxsaberза дополнение)). 
Возвращает true, если в очереди было событие, в ином случаи - false.


Возможен вариант использования:

//....
for(int i = 0; i < 10^6; ++i){
   // .... Data Calculations

   if((i % 10^3) == 0){
       while(HandleNextEvent(EVENT_TYPE_ALL));
   }
}
//....
 
fxsaber:

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

А вы проверяли данное утверждение на практике? Просто может оказаться все наоборот.

MqlTick состоит из примитивных типов данных, которые не инициализируются.
Соответственно, времени на выделение вообще не тратиться, так как это та же операция "sub esp", просто разного размера.
В результате bottleneck может вообще оказаться на стороне кеша процессора для операции чтение значения из памяти. 

В общем нужно тестить ))

 
Sergey Dzyublik:

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

Возможен вариант использования:

Очень красивое и полезное решение!

 
Sergey Dzyublik:

А вы проверяли данное утверждение на практике? Просто может оказаться все наоборот.

Теоретизирую здесь. Не проверял. Но передача по ссылке string видится целесообразной.

 
Sergey Dzyublik:

Возможен вариант использования:

что-то вы дичь какую-то предлагаете.

судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?

а если во время обработки опять будет вызов handlenextevent?

а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?

у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?

 
TheXpert:

1) что-то вы дичь какую-то предлагаете.
2) судя по сигнатуре и вашему описанию, терминал должен по функции вызвать обработку следующего события, а затем вернуть управление в программу в точку вызова handlenextevent?
3) а если во время обработки опять будет вызов handlenextevent?
4) а что случается в события которые не попадают под фильтр в параметрах? пропускаются? меняют очередность?


1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...
2) Все верно. Если меня интересует обработка конкретного события, а не всех имеющихся в системе, было бы не плохо предоставить возможность обработать только данный тип событий, оставив обработку остальных событий в обычном режиме.
3) Если во время обработки опять будет вызов HandleNextEvent - вызвать и обработать. Единственное что может быть - это переполнение стека, но это проблема пользователя и его кода, а не разработчиков.
4) События, которые не попадают под фильтр, остаются в той же последовательности и будут вызваны, когда пользователь вернет управление в систему, как обычно.


 
TheXpert:

у скриптов вообще нету очереди событий, зачем ее добавлять на костылях если есть советники и индикаторы?

Здесь пример скрипта, который асинхронно открывает и закрывает свои позиции/ордера.

// Максимально быстро все закрывает. Возврат, когда действие подтверждено.
bool CloseAll()
{
  uint RequestID[];
  
  for (int i = ArrayResize(RequestID, OrdersTotal()) - 1; i >= 0; i--)
    if (OrderSelect(i, SELECT_BY_POS))
      // Отправили асинхронный приказ
      RequestID[i] = (OrderType() <= OP_SELL) ? OrderCloseAsync(OrderTicket(), OrderLots(), OrderClosePrice(), 100) : OrderDeleteAsync(OrderTicket());
  
  return(Transactions.Waiting(RequestID)); // Дождались ответа от сервера на все асинхронные приказы
}
TradeTransactions
TradeTransactions
  • www.mql5.com
Асинхронные торговые приказы обладают огромным преимуществом - высокая скорость при массовой отправке. Однако, распространению таких приказов мешает некоторое неудобство - данные о результате приказа возможно увидеть только в OnTradeTransaction. Такое обстоятельство заставляет обывателя строить событийную модель своей ТС, если хочется...
 
Sergey Dzyublik:

1) Мое дело предложить, а дичь ли это, или нет - решать не вам, а разработчикам, им чуть-чуть виднее...

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

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