Discussion of article "LifeHack for traders: Fast food made of indicators" - page 4
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
There is no certainty that a user can speed up this process in a general way. Obviously, the overhead goes into calculating the hash function.
Exactly. So there is no resonance to make your hash function in OOP wrapper, since this function is already implemented behind the scenes of MT5 and works fast.
I didn't care about performance there, but it was clear that any hash function input should be an array of MqlParam values. And this can't work fast taking into account that there is a slow string-field.
Which means that it is already difficult to catch up with the system hash function at the user level, and it will be almost impossible to overtake it by a significant amount.
But the main thing in all this is that there is no significant overhead of Classic MT5 vs. MT4 Style, i.e. optimisation will do nothing.
I deleted my previous post because I noticed that MACD MQL4 style EA additionally accesses the graphics subsystem:
I.e. the testing done was performed incorrectly. After commenting the Comment function, the performance was almost equalised
If the author of the article had at least once run profiling (which is mandatory when measuring performance - self-control), such an unfortunate error in the conclusions would not have occurred.
I believed the results myself, but I shouldn't have. My fault.
If the author of the article had at least once started profiling (which is mandatory when measuring performance - self-control), such an unfortunate error in the conclusions would not have occurred.
I believed the results myself, but I shouldn't have. My mistake.
+
But then again, indicators and bars are evil.
I didn't get that idea.
Well, you wanted a lot of information dumped on the reader in one article.
I wanted objective conclusions.
But regarding your method - it's a head-on solution, have you tried others? And compared performance?
Yes, it is a frontal method, which fully justified itself, because it required accuracy and did not need any performance at all. The task was to close the interfering cleverness of MT5.
And others, of course, did not try, because
computational resources and memory to carry the baggage of a hundred handles through a hundred bars. But I haven't seen EAs in the same kodobase that would nail a handle like this. Everything is given to the "cleverness of MQL5", thus forcing the authors to be not clever at all.
Deleted my previous post because I noticed that MACD MQL4 style EA additionally accesses the graphics subsystem:
***
I entered "Comment" for testing purposes only. You can check the work in the tester, if you run"MACD MQL4 style EA short.mq5" in visual mode and place the cursor on the bar with index #1:
Figure 1. "MACD MQL4 style EA short.mh5" in tester
And it did not participate in the testing of the RATE in the tester:
I didn't get that idea.
I welcome bars and indicators in the form of drawings on the screen. But in EAs it is almost absurd.
People test EAs by real ticks, and for some reason they focus not on ticks, but on bars. And it would be fine if bars were built for each type of price (bid, ask, flipper), but this is not the case.
There is some kind of masochism when people voluntarily switch to historical data with a terrible loss of information. And on this fragment they try to cook up something, including the use of machine learning methods.
Here's another idea about smart MQL5. There are a lot of Expert Advisors, where the same indicator is called on each bar, but with different input parameters. MQL5 "shoots" unnecessary handles over time. But this is a universal solution. And in an Expert Advisor, the author can take this responsibility on himself, killing handles by himself. It is obvious that it is super-wasteful in terms of computational resources and memory to carry the baggage of a hundred handles through a hundred bars. But I haven't seen EAs in the same kodobase that would nail a handle like this. Everything is given to the "cleverness of MQL5", thus forcing the authors to be not clever at all.
Even the smartest work with handles will not help here. Only one thing will help: rewriting the indicator to the Expert Advisor's internal function with parameters.
Imho, all this is far from practical application. There is a possibility to release handles: of course, we can think of some academic example where this feature can be used instead of writing a fast internal function and using it (imho).
I entered "Comment" only for testing purposes. You can check the work in the tester, if you run"MACD MQL4 style EA short.mq5" in visual mode and place the cursor on the bar with index #1:
Figure 1. "MACD MQL4 style EA short.mh5" in tester
And it did not participate in the testing of the RATE in the tester:
I.e. there is still an overhead, and not a small one at that. Vladimir's example is more trustworthy, because the call was used in the real work of the advisor.
Even the cleverest work with handles will not help here. Only one thing will help: rewriting the indicator to the Expert Advisor's internal function with parameters.
This is also an argument in favour of "indicators are evil".