В MT4-тестере одиночный прогон в ~10 раз медленнее, чем в режиме оптимизации - страница 3

Новый комментарий
 
zaskok3:

Но не в разы же скорость понижается от этого. Можно пнуть приведенный выше советник, что в нем нет вычислений, поэтому легко показать ухудшение в разы. Но на моей ТС, с которой все началось, вычисления занимают бОльшую часть времени, нежели торговые операции. При этом замедление в ~10 раз.Доходит до смешного: ставлю мнимую оптимизацию в один прогон, чтобы не ждать в ~10 раз дольше одиночный. Факт, оптимизатор 10 проходов выполняет за то же время, что один проход без режима оптимизации. На веру, конечно, это. Доказательств не будет, т.к. достаточно того констурктива, что привел почти сразу.

Запись на диск вырубал:

Если графических объектов много, то скорость может понизиться в разы - мы поэтому исключили работу с графическими объектами в оптимизации. У Вас на каждом тике модификация ордера - каждый раз новый объект-чёрточка

Торговые операции в тестере принтуются сами, независимо от Вашего желания. Принт на каждом тике - вполне ожидаемое замедление. даже если Вы физически перекроете запись на диск, то всё равно останется трата времени на подготовку строки, которая выводится в лог

 
Slawa:

Если графических объектов много, то скорость может понизиться в разы - мы поэтому исключили работу с графическими объектами в оптимизации. У Вас на каждом тике модификация ордера - каждый раз новый объект-чёрточка

Торговые операции в тестере принтуются сами, независимо от Вашего желания. Принт на каждом тике - вполне ожидаемое замедление. даже если Вы физически перекроете запись на диск, то всё равно останется трата времени на подготовку строки, которая выводится в лог

Выходит, что это не баг, а, действительно, оптимизатор может быть быстрее в разы одиночного прогона, даже если в советнике самом отсутствуют графические объекты и логирование.


Возможно ли создание графических объектов не во время бэктеста, а по нажатию кнопки "Открыть график"? Ведь во вкладке "Результаты" есть все данные, чтобы сгенерировать в любой момент эти стрелочки, на которые если и смотрят, то в 10% в лучшем случае.


Стало интересно, как повлияет на скорость отказ от OrderModify:

//    else if (GetOrder(i))
//      OrderModify(OrderTicket(), OrderOpenPrice(), OrderStopLoss(), OrderOpenPrice() * 2 * (i %2 ), 0);


Результат:


Увеличивающуюся вправо "пушистость" объяснить пока себе не могу однозначно. Но хорошо видно, что отключение OrderModify увеличила производительность одиночного прогона аж в два раза! При этом огромные провалы после 10К и 100К ордеров в истории остались. Как заставить тестер не проваливаться, а показывать более-менее стабильную производительность, как и при включенной оптимизации? Хотя и там странности:

zaskok3:

ЗЫ Присмотрелся к красному графику (тестер в режиме оптимизации). Там провал производительности происходит при увеличении числа ордеров на истории четко на 50К штук. Но потом скорость восстанавливается к прежним значениям.

 

Решил посмотреть, как влияет наличие OrderModify на производительность тестера в режиме Оптимизации. Вроде, сильно не должн влиять, т.к. тормозные принудительные графические объекты там отсутствуют. Результат:

Отключение OrderModify в режиме оптимизации ускорило выполнение в 3.5 раза! И графические объекты тут не при чем. Это насколько же прожорливая функция получается....

Провалы через каждые 50К ордеров еще лучше видны на графике.

 
Если запустить советник из этой ветки в тестере и сразу переключиться на вкладку "Результаты", то происходит зависание терминала с заголовком "Не отвечает". Это продолжается несколько секунд.
 

Появилось предположение, что тормозит ненулевой TakeProfit, поэтому сделал такое изменение в советнике:

//      OrderSend(Symbol(), OP_BUY, Lots, Ask, 0, 0, 0, NULL, i);
      OrderSend(Symbol(), OP_BUY, Lots, Ask, 0, 0, Ask + Ask, NULL, i);
    }
//    else if (GetOrder(i))
//      OrderModify(OrderTicket(), OrderOpenPrice(), OrderStopLoss(), OrderOpenPrice() * 2 * (i %2 ), 0);


Это заставляет тестер каждый раз проверять TakeProfit. Но по результатам получил уменьшение производительность только на ~10%. Т.е. далеко не в разы. Так что можно констатировать:

Старайтесь по возможности избегать использования OrderModify в советниках для тестера, иначе возможно замедление теста в разы (вне зависимости, одиночный это прогон или оптимизация).

 
Slawa:

Если графических объектов много, то скорость может понизиться в разы - мы поэтому исключили работу с графическими объектами в оптимизации. У Вас на каждом тике модификация ордера - каждый раз новый объект-чёрточка

Торговые операции в тестере принтуются сами, независимо от Вашего желания. Принт на каждом тике - вполне ожидаемое замедление. даже если Вы физически перекроете запись на диск, то всё равно останется трата времени на подготовку строки, которая выводится в лог

Было бы неплохо, если бы вывод в журнал модификаций был бы вынесен в опцию настроек тестера. Так как большинству не нужно знать где находились ордера во время модификации. А если при тесте тысячи модификаций то смысл журнала вообще практически исчезает. Информация о модификациях нужна при прогонах в очень редких случаях.

Так же странно, что отрисовка объектов при одиночном прогоне не отключена. Все равно же их никто не видит. Но это же вроде замедляет прогон.

 
ANG3110:

Было бы неплохо, если бы вывод в журнал модификаций был бы вынесен в опцию настроек тестера. Так как большинству не нужно знать где находились ордера во время модификации. А если при тесте тысячи модификаций то смысл журнала вообще практически исчезает. Информация о модификациях нужна при прогонах в очень редких случаях.

Подтвреждаю. Если ту же канальную ТС делать на лимитниках, то весь журнал будет в одних модификациях. И ничего не разобрать.

Опций настроек тестера, однозначно, не хватает. То же логирование логично отключать во многих ситуациях. А не генерить гигабайты логов, когда туда даже заглядывать не собираешься.

Очень много лишних телодвижений совершает тестер.

 

Во время оптимизации - нужны только результаты оптимизации и параметры. Все это должно быть записано во временный массив. Никакие объекты, сделки и модификации не сохранять. При одиночном прогоне без оптимизации нужно результаты теста сохранять во временный массив, а информацию для рисования (обекты, индикаторы), во второй временный массив. Никаких объектов сразу не выводить. Если нажата кнопка график - читается из массива и отрисовываются объекты. Если нажаты результаты, читается из массива и выводится результат. С модификациями нужна опция показывать ли их или нет. Если да, то в логи пишется все подряд. Если нет, то никаких модификаций писать не нужно. Еще нужна опция сохранять ли логи. Если нет то они должны удаляться сразу или перед следующим тестом или при закрытии терминала.

Я как-то один раз смотрю у меня на жестком диске С заканчивается память (300 ГГб). Стал смотреть почему. А оказалось один терминал нагенерировал 200ГГб логов. Вообще по большому счету логи нужны скорее при визуализации или при ошибках. Более в них практически никто не смотрит. (Мое мнение, что идеализация логов, в частности в МТ5 вызывает отталкивание у потребителей). Результаты тестов должны быть четкие, конкретные и ясные. Остальное все, только для специфических режимов отладки.

 

zaskok3:

При этом огромные провалы после 10К и 100К ордеров в истории остались. Как заставить тестер не проваливаться, а показывать более-менее стабильную производительность, как и при включенной оптимизации?

Победил заразу! Надо в перед выходом из OnTick сделать вызов ObjectsDeleteAll(). Теперь, пусть и медленней, чем в оптимизаторе, но не супер-напряжно дожидаться конца одиночного прогона тестера, когда OrdersHistoryTotal() > 10K.

Старайтесь по возможности избегать использования OrderModify в советниках для тестера, иначе возможно замедление теста в разы (вне зависимости, одиночный это прогон или оптимизация).
Эта беда осталась не решенной. Разработчики прекратили комментировать...
 
В режиме оптимизации в ГА очень часто несколько проходов считаются многие минуты. Хотел бы разобраться, на каких входных параметрах это происходит. К сожалению, тестер не выдает никакой информации о текущем проходе в режиме оптимизации.

Каким образом это можно узнать? Пришел в голову только такой вариант (поведение глобальных переменных не изучал):

  1. в OnInit открываю файл и дописываю в него входные параметры. Затем FileClose.
  2. в OnDeinit дописываю еще время расчета. Затем FileClose.
В файле будет видно, какие проходы сколько считались. И даже если оптимизатор будет не дождаться, то все равно можно будет увидеть, на каком проходе он застрял.

Поэтому еще несколько вопросов:

  1. Не убьют ли такие тысячи дозаписисей SSD-диск? RAM-диск желателен?
  2. Есть ли возможность выводить в журнал хоть что-нибудь в режиме оптимизации?
  3. Во время форс-прерывания прогона самим оптимизатором (например, стоит ограничение на макс. просадку), будет вызываться OnDeinit и/или OnTester (не проверил еще)?
123456
Новый комментарий
Причина обращения: