MT5 and speed in action - page 23
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
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.
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:
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?
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.
The HistorySelect documentation explicitly states:
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.
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.
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.
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).
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?
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.
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 documentation, where to read about them?
Most likely after the next release version (now in beta)