![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
You could just have a longer interval. At least 30 seconds for the test.
With normalisation.
Without normalization.
Same 20%.
This is how one Agent works, consistently counts the same thing. If you take away all the randomness, the net performance is close to the shortest.
Net is not interesting, as it is not achievable in reality.
Thanks for the tests.
With normalization.
Without normalisation.
The same 20%.
20% for a dummy EA that does nothing... It's not very significant. In real code, the figure would be many times less. Is it worth wasting time on such trivialities.
And speaking of optimising calculations, we should start with the fact that there is no need to constantly monitor levels of all pending orders. We only need to check the closest one. If it is reached, then the next level and so on.
20% for a dummy EA that does nothing... It's not very meaningful. In real code the figure would be many times less. Is it worth wasting time on such trivialities.
The observation is fair. On my normal robot I see too much lag in the Tester. There are many reasons for this. And this is one of them. One pass is 100 million ticks. Take the standard genetics for 10K passes. That's a trillion ticks at least. On every tick the tester does at least one normalization. When it could do none at all. What is the saving on such optimization? Moreover, to bother is to do a normalisation at every comparison, as is happening now. It's actually easier and more efficient to normalise only the incoming prices.
And speaking of the optimization of calculations, we must start with the fact that we do not need to constantly monitor levels of all pending orders. We only need to check the closest one. If it is reached, the next level is checked, etc.
The built-in tester lags dramatically when the number of orders increases. The grid TS are its "killers". I have suggested such algorithmic optimization. I do not think they will undertake it.
Here we are not discussing a large amount of internal calculations accompanying each tick of the tester.