MT5 and speed in action - page 4

New comment
 
I understand it all depends on the equipment
 
Alexsandr San:
I understand it depends on the equipment

Not at all!

2020.05.29 15:08:44.938 Terminal        Windows 7 Service Pack 1 build 7601, Intel Core i7-6850 K  @ 3.60 GHz, 23 / 31 Gb memory, 43 / 226 Gb disk, IE 11, UAC, Admin, GMT+3
 
Alexsandr San:
I guess it depends on the hardware.

I don't think so ))))

And not even from a busy computer...

 
prostotrader:

Not at all!

yes! your machine and the previous one have different results - so I'm wrong, not the power means

 
Aleksey Mavrin:

What is onMain? How can there be more than one event in the queue in onMain if each event calls onMain to handle the queue?

OnMain is a function. It is not actual code, but a special case - an answer to the claim "There is no way to know the state of the current real queuewhile running the OnMain function".It is a different approach to the calculations themselves

 
A100:

OnMain is a function. It's not the actual code, but a special case - an answer to the claim "There's no way to know the state of the current real queueduring OnMain function execution".This is a different approach to the calculations themselves

So, just in case, OnMain...

:) ;)
 
fxsaber:


In Combat Advisors, I've wrapped functions everywhere in suspicious places to _B(FuncName(...), AlertTime). Here's a short excerpt of the log from the most recent entries.

The time column shows how often freezes occur.

You are substituting concepts.

Here is your original statement:

Unfortunately, such a HistorySelect call lasts 5-30 milliseconds (measured it myself in Release-EX5). When the Expert Advisor makes several such updates in OnTick (in a good way, it should be done after any pause. For example, after each OrderSend.), then everything becomes insanely expensive/long. HistorySelect can add up to several seconds in a single OnTick.

Even in your terminal, the average time of 0.2ms per call is measurably less than the values specified in the original statement.

Now you're saying that sometimes the runtime of a function can be noticeably longer than the average. This is a different question.

Any HistorySelect() request is a full-fledged call to the terminal bases under synchronizers. This is unavoidable. Yes, taking into account the presence of access synchronization, we cannot guarantee a very short time of this function's execution.

The proposed solution by adding the functions HistoryDealsSelect() and HistoryOrdersSelect() changes absolutely nothing in this sense.

The script for checking the maximum and average time:

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:

A script to check the maximum and average times:

I will not comment on your opinion before quoted. Here is the result of running your script.

More precisely, I couldn't wait for it to finish, so I changed the number of iterations from 100K to 1K.

        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

Does this even merit a satisfactory grade?

Look at the absurdity of the situation. In order to stupidly find out the number of deals we need to call HistorySelect! This, to put it mildly, is not rational.


I spend at best tens of milliseconds on each tick only because of HistorySelect.

 
A100:

In its simplest form:

You just need to change your approach to the calculations themselves (do intermediate return as often as required by the task). But if it's complicated, consider at the 1st stage that OnMain is absent for you (you put the main code not in OnMain but in OnTrade2XX), therefore you don't need to learn anything in OnMain

Thanks, that's exactly how I understood it from the beginning and that's why I said that you don't fully understand it. Here's an example of a simple scenario.


You do an OrderSend. If a certain position has not closed on the mark right after OrderSend, you make another OrderSend. This is all logic, which needs to be programmed. Async is not used.


Now the situation that happened for our robot. You have sent an OrderSend and while it is being executed the Limiter has triggered and the TP of the position mentioned above has been executed.


What is the implementation of the robot schematically? I don't know how to implement it without braking HistorySelect or OnTradeTransaction-spy crutch that gives access to the entire history of transactions in any place of the code. If a mechanism for accessing the event queue was implemented, the example above would be solved elementary.


Everyone strong in MT5, including developers, please show me how to implement this( two linesin bold above) uncomplicated (I'm afraid to even mention complex) trading logic.

 
A100:

OnMain is a function. This is not the actual code, but a special case - an answer to the claim " There is no way to know the state of the current real queue during OnMain function execution".This is a different approach to the calculations themselves

Well, it is, isn't it. And that's what the guys were talking about. In order to implement it, you must change the structure of execution of MQL programs, either a) at least into a two-threaded one or b) add a mechanism to access the queue and control its handling.

With the current structure, your proposed scheme is impossible to implement.

1234567891011...94
New comment