MetaTrader 5 Strategy Tester: bugs, bugs, suggestions for improvement - page 18
![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
1. At the moment there is a limit of 100,000,000 (100 million) passes for a full optimization run. Previously (in MT4) this limit was 1 million, and that suited you. How many do you need?
2. Portable mode is not necessary to store data in different folders. Or don't you want to search for data in the AppData directory?
As for complicating data storage, ask Microsoft. We introduced portable mode just to keep the storage the same as before, how do you see the complication?
1- Attaching pictures. There's 30 lakh variants, but there's genetic optimization going on, not overshooting. Although up to 100 lm should be overkill... And in general I need to estimate the acceptable time for optimization myself, regardless of the number of variants.
2- I want to be able to put 10 terminals for example... and not to think how to do it. I am not a programmer (in my heart), I am not interested in copying something or prescribing something specially...
Are there plans for Real Tick Optimisation to store tick history (and bars can, if only zero bar generation is done) in memory in one place for all local Agents at once?
Yes, it is planned
1- I attach pictures. There are 30 million variants, but it's genetic optimization, not overkill. Although up to 100 million variants should be overkill... In general, I need to estimate the acceptable time for optimization myself, regardless of the number of variants.
2- I want to be able to put 10 terminals for example... and not to think how to do it. I am not a programmer (at heart), I am not interested in copying something or prescribing something specially...
1. Install the 64-bit version of the client terminal.
In the 32-bit version the limit of full enumeration is 1 million
2. Just put 10 terminals in 10 different folders as you did before. What's the problem?
Thank you. Is the Real Tick Optimization planning to store tick history (and bars can, if only zero bar generation is done) in memory in one place for all local Agents at once? Now, unfortunately, each Agent works (judging by memory consumption) with its own copy of tick history.
Raised this topic. It was promised back in the REALIZE before last.
Apart from the fact that all huge sets of temporary files with tick cache are different for each agent, they are also deleted too fast. Whether by time or every extraneous action, even if it doesn't affect the validity of the next single test. I.e. even without compilation or parameter changes the next test tens of gigs (with a long history) are generated all over again. A few minutes.
It's about a few builds ago. Haven't optimised on ticks in quite a while. So far. But I think it's the same.1. Install the 64-bit version of the client terminal.
In the 32-bit version the limit of full enumeration is 1 million
2. Just put 10 terminals in 10 different folders like you did before. What's the problem?
Thank you) I will try it.
But the suggestion to make a revocable limit stands!!!There is also a lack of a filter in the tester results.
For example, I don't want results with less than 10 trades. Or more than 50. Or expected payoff below....
In order to further select by other parameters, for example by drawdown, but without parameters I obviously do not need.
You can enable the filter, for example, in the menu by clicking the right button on a column header.
You can do the same in MT4!
What's missing is a filter in the tester results.
This is a really important feature that is occasionally mentioned on the forum.
Currently implemented indirectly either via OnTester or directly via opt-file filter (creating your own).
Ran a 15 year run on the same character in 11 threads (one thread counts other things).
The question is this. Why should each thread unpack its own copy of the history, raping the disk N times? Or am I mistaken? But judging by my previous runs, that's exactly what happens.
You can make a single file and mapping to it... There is much less cache and load on disk.
Another result) I'll try running with 8 cores)
It didn't work) All sorts of errors keep coming up...