MT5 and speed in action - page 23

New comment
 
Renat Fatkhullin:

In case anyone doesn't get it, it's the fxsaber library which when applied in someone else's code gives brakes.

Instead of explicitly pointing this out, he started playing the game about platform braking and slipping suicidal examples. And when there was an opportunity to get to the real cause and iron out the issue, he didn't take it.

For the sake of local optimization it was poisoning the history cache for the main application.

Forum on trading, automated trading systems and testing trading strategies

MT5 and speed in action

fxsaber, 2020.09.02 00:02

There was a clean MQL5 code reproducible by many. The chronology of the thread first study, instead of playing conspiracy theory, that someone needs you so much that he is willing to spend his time on you for mudslinging.

You're doing a great job as a turkey. There has been no discussion of any libraries here specifically in the thread as it is not constructive.

The point is that if someone ventures to use shared libraries where the from-input parameter doesn't coincide, they will get brakes. There is no mention of this anywhere in the Documentation. At least something about it was taken out of you with pincers. And when it was done, they started accusing you of cheating.


This feature of MQL should be written in the Documentation and the Features branch. Run the clean MQL5 scripts from this branch on the builds corresponding to the dates of their creation. Apparently, so many fixes were made blindly just in case.

 
fxsaber:

You are doing a great job as an indie. No libraries were specifically mentioned here in the thread, because it's not constructive.

Because you have done your best not to blab about your libraries. In the presence of these libraries. With the constant opposition of "mine is faster". So you've cleverly masked the self-shooting by sticking out "look how slow it is".


The point is that if one dares to use shared libraries where the from-input parameter is not the same, one will get lags. There is no mention of this anywhere in the Documentation. At least something about it was taken out of you with pincers. And when it was done, they started accusing you of cheating.


This feature of MQL should be written in the Documentation and the Features branch. Run the clean MQL5 scripts from this branch on the builds corresponding to the dates of their creation. Apparently, so many fixes were made blindly just in case.

The HistorySelect documentation clearly states:

The HistorySelect() function creates a list of orders and a list of deals in the mql5 program for further reference to the elements of the list via the appropriate functions. The size of the deals list can be obtained using the HistoryDealsTotal() function, and the size of the orders list in the history can be obtained using the HistoryOrdersTotal() function. The enumeration of elements in the list of orders is best performed using the HistoryOrderGetTicket() function, for the elements of the deals list, the HistoryDealGetTicket() function is appropriate.

After the use of the HistoryOrderSelect() function, the list of orders in the history, available to mql5-program, is reset and re-filled with the order, if the search of order by ticket has been successfully completed. The same applies to the list of deals, which are available for the mql5-program - it is reset using the HistoryDealSelect() function and re-filled if a deal is successfully obtained by the ticket number.


When you are working with huge volumes (and you showed thousands and tens of thousands of deals in the history for a reason), which require atomic/snapshot access, you need to understand their cost.

Especially since I have explained the technical details of these caches in great detail in this thread.


Have you tried for nothing to randomise each sample and poison the cache as much as possible? For the sake of your position any self-shooting is in order?

 
Renat Fatkhullin:

Because you did everything you could to keep your libraries quiet. That's why you cleverly masked the self-inflicted bugs by flaunting "look how slow it is".

99% of bugs are found this way. First the odd behaviour is found in the big code. Then localisation finds the cause. I was more concerned about the brakes.

trading functions. The problems are almost everywhere.

KD      0       16:00:33.382    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 34: HistoryOrderSelect(0)] = 25 ms.
PE      0       16:00:44.913    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 17: CopyTicks(Symb,Ticks,COPY_TICKS_ALL,0,1)] = 24 ms.
DP      0       16:00:44.888    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 46 ms.
FI      0       16:00:49.579    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 28: HistoryDealSelect(0)] = 22 ms.
EE      0       16:01:03.287    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 33: HistoryOrderGetDouble(0,ORDER_PRICE_CURRENT)] = 1 ms.
KE      0       16:01:07.013    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 50: OrderGetDouble(ORDER_PRICE_CURRENT)] = 1 ms.
JM      0       16:01:12.189    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 44: TimeCurrent()] = 39 ms.
MD      0       16:01:13.067    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 81: ResourceFree(NULL)] = 1 ms.
RS      0       16:01:13.572    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 41: SymbolInfoDouble(Symb,SYMBOL_POINT)] = 7 ms.
GL      0       16:01:27.816    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 79: GlobalVariableGet(NULL)] = 22 ms.
PD      0       16:01:33.892    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 58: PositionGetInteger(POSITION_MAGIC)] = 1 ms.
KP      0       16:01:39.864    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 67: OrderCheck(Request,CheckResult)] = 3 ms.
ML      0       16:01:39.970    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 62: AccountInfoInteger(ACCOUNT_MARGIN_MODE)] = 1 ms.
KM      0       16:01:41.045    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 55: PositionSelect(Symb)] = 2 ms.
NS      0       16:01:46.832    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 78: GlobalVariableCheck(NULL)] = 1 ms.
JP      0       16:01:49.211    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 75: SymbolName(0,true)] = 1 ms.
EL      0       16:01:59.101    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 19: CopyTicksRange(Symb,Ticks,COPY_TICKS_ALL,Tick.time_msc)] = 32 ms.
IM      0       16:02:07.462    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 70: AccountInfoInteger(ACCOUNT_TRADE_EXPERT)] = 7 ms.
PJ      0       16:02:11.735    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 37: IsStopped()] = 4 ms.
OG      0       16:03:08.178    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 32: HistoryOrderGetInteger(0,ORDER_MAGIC)] = 14 ms.
JH      0       16:03:16.385    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 40: SymbolInfoDouble(Symb,SYMBOL_TRADE_TICK_VALUE)] = 5 ms.
FM      0       16:03:16.601    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 59: PositionGetString(POSITION_SYMBOL)] = 1 ms.
GH      0       16:03:21.841    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 72: TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)] = 1 ms.
FJ      0       16:03:25.782    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 46: TimeTradeServer()] = 1 ms.
EO      0       16:03:26.772    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 45: TimeLocal()] = 10 ms.
HD      0       16:03:36.595    fxstest (EURUSD,M1)     Alert: Time[fxstest.mq5 13: SymbolInfoTick(Symb,Tick)] = 13 ms.
...
The man decided to help and ran a clean MQL5 code on his machine. A small sample above. Read the names of the functions above.


The HistorySelect documentation explicitly states:

The HistorySelect() function creates a list of orders and a list of trades in the mql5 program for further reference to the items in the list via the appropriate functions. The size of the deals list can be obtained using the HistoryDealsTotal() function, and the size of the orders list in the history can be obtained using the HistoryOrdersTotal() function. The enumeration of elements in the list of orders is best performed using the HistoryOrderGetTicket() function, for the elements of the deals list, the HistoryDealGetTicket() function is appropriate.

After the use of the HistoryOrderSelect() function, the list of orders in the history, available to mql5-program, is reset and re-filled with the order, if the search of order by ticket has been successfully completed. The same applies to the list of deals, which are available for the mql5-program - it is reset using the HistoryDealSelect() function and re-filled if a deal is successfully obtained by the ticket number.

I wonder who saw something between the lines in this text? Personally, I have understood (before this branch), that HistoryDealSelect and HistoryOrderSelect must be written like this.

  static bool HistorySelectOrder( const ulong Ticket )
  {
    return((::HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket) || ::HistoryOrderSelect(Ticket));
  }

  static bool HistorySelectDeal( const ulong &Ticket )
  {
    return((::HistoryDealGetInteger(Ticket, DEAL_TICKET) == Ticket) || ::HistoryDealSelect(Ticket));
  }

Otherwise, you are guaranteed to encounter lags.

When you work with huge volumes, requiring atomic/snapshot access, you need to understand their cost.

All the more so, since I've explained the technical details of these caches in great detail in this thread.

I've been picking up the necessary information in this thread.

 
Renat Fatkhullin:

Have you tried for nothing to randomise each sample and poison the cache as much as possible? For the sake of your position any self-shooting is in order?

You can see everything chronologically in this thread. The problem was originally shown without any randoms.

This thread is a great testament to how you can twist your opponent's words. All the sources and their results are saved here.

 

Why can't the terminal just increase the cache when the full history is requested again, retrieve and cache the missing range? That would seem to solve the problem. After all, when requesting bars/tickets, missing data packets are returned, so there is a mechanism for this.

 
Aleksey Vyazmikin:

Why can't the terminal just increase the cache when the full history is requested again, retrieve and cache the missing range?

This has already been done.

But if between HistorySelect( 0, INT_MAX ) callsHistorySelect( other_time, ... ), the cache will be rebuilt starting from other_time and nextHistorySelect( 0,... ) request will lead to new cache building (will be slower).

 
Andrey Khatimlianskii:

This has already been done.

But if between calls of HistorySelect( 0, INT_MAX ) we callHistorySelect( other_time, ... ), the cache will be rebuilt starting from other_time and the nextHistorySelect( 0,... ) request will lead to new cache building (it will be slower).

If you've done it, it's good, the only question is then about convenience of work with received data, provided the cache is built up.

I didn't understand trading operations so deeply, but if query range changes, then there is no possibility to quickly search data inside history without full brute force?

 
Aleksey Vyazmikin:

I'm not that deep into trading, but if the range of the query changes, then there's no way to quickly search for data within the story without a full enumeration?

What's the point of this knowledge if you don't use it?

No practical problem = no question.

 
Renat Fatkhullin:

OrderExist and PositionExist are special optimised functions that avoid stupid looping through all orders or positions in search of entries by symbol, transaction type and medzhik.

The result is an array of tickets.


Programs may save a lot of money using these functions. Especially when calling open positions and orders in bulk, constantly and repeatedly in overshoot loops.

We will implement more effective functions to access massive trade data in the future.

The language will also be dramatically strengthened and simplified with more powerful functionality.

" OrderExist and PositionExist" - not found in the documentation, where can I read about them?
 
HimOrik:
" OrderExist and PositionExist" - not found in documentation, where to read about them?

Most likely after the next release version (now in beta)

1...161718192021222324252627282930...94
New comment