MT5 and speed in action - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Please give a rudimentary diagram-code for this idea. At first glance it sounds like a complete misunderstanding.
During execution of OnMain function there is no way to know state of current real queue. The only workaround to do this is a spyware program, as given in the link.
In its simplest form:
OnXXX( параметры ) { запомнить параметры (поместить в очередь) OnMain(); } On2XX( параметры ) { /*вычисления*/ поменять приоритет обработки событий (если нужно) /*вычисления*/ промежуточный return (если нужно) /*вычисления*/ } void OnMain() { прочитать приоритет обработки событий для каждой группы событий извлечь параметры из очереди OnTradeXXX( параметры ) удалить событие из очереди }You just need to change the approach to the calculations themselves (do intermediate return as often as the task requires). But if it is difficult, consider at the 1-step that OnMain does not exist for you (you move the main code not in OnMain, but in On2XX), respectively, in OnMain you don't need to learn anything
Crutches are being made in the wrong direction:
Leave the OnXXX functions only copying events (parameters) in the queue and calling the main OnMain function. Move all their code to duplicate On2XX functions. And call these duplicating On2XX functions from the OnMain in the sequence in which you need, passing them in turn the data from the queues as parameters.
Then run measurements and show the speed gain, and then you can suggest to complement MQL with appropriate functionality. But why add, if you have already done everything yourself here and now?
That's not what you're writing about.
The problem is that the functionality of filling fields in input variables of "OntaredeTransaction" function does not correspond to the description given in Help, for the worse:
i.e. many fields are not filled in calls and even in final call of TRADE_TRANSACTION_HISTORY_ADD.
Consequently, all traders are agonizing here to somehow determine these missing parameters at the moment of arrival.
There were many discussions here, just do a search on the forum - poor "OntaredeTransaction" functionality causes additional expenses both in time and "loads" traders with extra time spent on development of adequately working code (i.e. huge time losses and colossal ineffectiveness at community level).
The current replies from developers like "If you have a Market execution symbol, it will have zero price value; it should be like this" (Link).(Link) - this is UNNORMAL, once again -
lack of exhaustive values in the last function call leads to a lot of extra work.
HistorySelect.
This is an insanely expensive feature. And unfortunately, no amount of caching can make its speed acceptable now.
For example, in battlefield EAs it is important to work with actual data. In particular, that the ticks from Market Watch and CopyTicks are not outdated if possible.
To do this, there are not very good, but forced mechanisms to check the relevance of current price data. One part of this mechanism is to detect situations where a trade on a symbol has passed later than the last tick. This does not happen rarely, so it is important to know if the current tick is still up to date or not.
For this detection, you need to be able to access the history of recent deals. It is done using the HistorySelect in the following schematic way.
Unfortunately, such a call of HistorySelect takes 5-30 milliseconds (I measured it myself in Release-EX5). When the Expert Advisor makes several such updates in OnTick (it should be done after any pause, for example, after each OrderSend), then everything becomes insanely expensive/long. HistorySelect can collectively eat up several seconds in a single OnTick.
Dear developers, why is it so expensive? This function can execute instantly with proper implementation.
Do you have evidence about "such a call to HistorySelect lasts 5-30 milliseconds"?
If I understood your idea correctly, then the test code should look like this:
This is how 100000 queries work:
Do you have evidence about "such a call to HistorySelect lasts 5-30 milliseconds"?
If I understood your point correctly, then the test code should look like this:
This is how 100,000 queries work:
Do you have evidence about "such a call to HistorySelect lasts 5-30 milliseconds"?
If I understood your point correctly, then the test code should look like this:
This is how 100,000 queries work:
Running your script.
Launch another script.
Normal battle count. Not HFT.
By the way, your script showed that HistorySelect recalculates everything every time. And the input parameters didn't change, the history table wasn't updated, other HistorySelect functions weren't called.
Running your script.
Then details are needed.
My test was running on not the fastest "Intel Xeon E5-2630 v4 @ 2.20GHz" with a lot of other processes in the background.
The test account had 31315 orders in its history more or less evenly since 2009, including 8 orders for today.
Perhaps, you had some script or Expert Advisor running at the same time causing a drastic loading of the terminal databases. Try it on a "clean" terminal.
More informative test:
Three runs:
Then details are needed.
My test was running on not the fastest "Intel Xeon E5-2630 v4 @ 2.20GHz" with lots of other processes in the background.
The test account had 31315 orders in its history more or less evenly since 2009, including 8 orders for today.
Perhaps, you had some script or Expert Advisor running at the same time which has drastically loaded the terminal databases. Try it on a "clean" terminal.
Empty Terminal on the same account and machine.
On other accounts and Terminals the same picture. Configuration.
I ask readers to give their results of this script.
A more informative test:
Three starts:
Empty Terminal 2460.
ZS Run on empty account.
The speed seems to be strongly influenced by the number of trades, not orders.
Empty Terminal on the same account and machine.
On other accounts and Terminals the same pattern. Configuration.
I ask readers to quote their results of this script.
It doesn't prove anything, but the fact that with every new run (on a different symbol), the time increases - is alarming...
Need to run on an account with a long trading history.