В MT4-тестере одиночный прогон в ~10 раз медленнее, чем в режиме оптимизации - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как сделать, чтобы одиночный прогон не тормозил?
Вопрос ставится неправильно.
Правильнее: за счет каких функций оптимизатор со второго прохода начинает работать быстрее?
Ответ прост: за счет кешей, созданных на первом проходе.
Запустил одиночный прогон и.... вместо пятикратного увеличения времени, получил замедление в сотни раз...
1. Есть нюанс работы с графическими объектами.
При одиночном тестировании, даже если Вы не работаете с графическими объектами, то стрелки торговых операций всё равно насильно создаются на графике тестирования (визуальном или виртуальном)
При оптимизации никакая работа с графическими объектами не допускается. Даже стрелки торговых операций не выставляются.
2. Ещё есть нюанс с логированием. При оптимизации в лог тестера не выводится ничего.
https://www.mql5.com/ru/articles/1512
Вопрос ставится неправильно.
Правильнее: за счет каких функций оптимизатор со второго прохода начинает работать быстрее?
Ответ прост: за счет кешей, созданных на первом проходе.
Исходник советника есть, так что никто не мешает вам вопроизвести и убедиться самому в несколько кликов мыши.
...оптимизация мнимая: количество вариантов для оптимизации задаю в виде один штука. Предварительно, конечно, избавившись от кэшей оптимизатора.
3. При одиночном тестировании генерация тиков происходит каждый раз. При оптимизации используется однократно созданный кеш сгенерированных тиков, даже в том случае, когда Вы прерывали оптимизацию
Но про это Вам уже сказали
1. Есть нюанс работы с графическими объектами.
При одиночном тестировании, даже если Вы не работаете с графическими объектами, то стрелки торговых операций всё равно насильно создаются на графике тестирования (визуальном или виртуальном)
При оптимизации никакая работа с графическими объектами не допускается. Даже стрелки торговых операций не выставляются.
Но не в разы же скорость понижается от этого. Можно пнуть приведенный выше советник, что в нем нет вычислений, поэтому легко показать ухудшение в разы. Но на моей ТС, с которой все началось, вычисления занимают бОльшую часть времени, нежели торговые операции. При этом замедление в ~10 раз.Доходит до смешного: ставлю мнимую оптимизацию в один прогон, чтобы не ждать в ~10 раз дольше одиночный. Факт, оптимизатор 10 проходов выполняет за то же время, что один проход без режима оптимизации. На веру, конечно, это. Доказательств не будет, т.к. достаточно того констурктива, что привел почти сразу.
2. Ещё есть нюанс с логированием. При оптимизации в лог тестера не выводится ничего.
https://www.mql5.com/ru/articles/1512
Запись на диск вырубал:
zaskok3:
В логи ничего не принтую. Пробовал сделать read-only SSD-папку tester/logs/ - не помогает.
3. При одиночном тестировании генерация тиков происходит каждый раз. При оптимизации используется однократно созданный кеш сгенерированных тиков, даже в том случае, когда Вы прерывали оптимизацию
Этот ужас победил:
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
zaskok3, 2016.01.13 18:08
Лог одиночного прогона пустого советника в MT4-тестере по ценам открытия:
Из лога видно, что сам советник проходит историю за нулевое время. Подготовка же исторических данных занимает пять секунд (немного больше 100К баров). Раньше такого не было.
Воспроизводится в 100% случаев. MT4 build 950, Windows7 SP1 x64.
Подскажите, какой крайний билд не страдает этим недугом. DOWNGRADE необходим.Сделал FXT read-only. Пятисекундная перестройка исчезла, теперь быстро, как раньше.
Даже пятикратного увеличения не должно быть. Т.к. основное время затрачивается именно на работу самого тестера стратегий.
Не понял логики. Если несколько моноТС объединяются в одну мультиТС, то время теста мультиТС даже теоретически не должно быть меньше суммы времен соответствующих моноТС.
А на практике должно быть больше. Т.к. OrdersTotal (не исторический) увеличивается, и поиск "своих" ордеров начинает занимать больше времени.
Не понял логики. Если несколько моноТС объединяются в одну мультиТС, то время теста мультиТС даже теоретически не должно быть меньше суммы времен соответствующих моноТС.
А на практике должно быть больше. Т.к. OrdersTotal (не исторический) увеличивается, и поиск "своих" ордеров начинает занимать больше времени.
Логика проста: основное время тестирования тратится на сам прогон данных. Не на расчет пользовательских данных, не на условия открытия и закрытия, а именно на прогон данных и эмуляцию торгового окружения. (Конечно, особенно ресурсоемкие вычисления - другая тема). Поэтому несколько стратегий за один прогон гонять гораздо выгодней: так как они используют одну инфраструктуру.
Прогон данных - это цикл for. А вот подготовка таймсерий в тестере - пожалуй, самая затратная его часть. Хотя, если там все сделано грамотно, и это должно быть ну очень быстрым. По крайней мере, в своих "тестерах" на это практически ничего не тратилось.
Проще всего - взять какой-нибудь класс стратегии. Вынести во входной параметр количество таких ТС и прогнать в оптимизаторе, замерив время. Построить график и сюда выложить. Сомневаюсь, что это кому-нибудь надо.