Замедление работы при тестировании

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

Привет!

Написал вчера одного Советника, бежит на дневных свечах, всего около 800 сделок (>10 лет истории). Пока не было отложенных ордеров (которые периодически добавляются/удаляются) бежал шустро до победного. С отложенными, примерно 50% ~ 400 сделок проскакивает одним махом, а затем начинает тормозить. Сам МТ потребляет при этом всего около 10МБ памяти. Комп довольно сильный, так что дело не в железе. Все циклы связанны только с проверкой открытых ордеров.

Может кто-то сталкивался с подобными проблемами? Какие-нибудь идеи?

Спасибо!

 
а что в диспетчере задач?
- похоже на превышение границ RAM, например каждый вызов индикатора с иными чем раньше параметрами создает копию в RAM со всеми таймсериjaми
 
Korey писал(а) >>
а что в диспетчере задач?
- похоже на превышение границ RAM, например каждый вызов индикатора с иными чем раньше параметрами создает копию в RAM со всеми таймсериjaми

CPU по процессу колеблется в пределах 39-49%. Памяти всего 4ГБ, примерно половина свободна. Мне показалось странным что замедление происходит резко, одним махом, причем после этого Тестер просто еле движется. В то же время по компу не скажешь что он становится заторможенным, может немного сильнее обычного. Думал может это из-за большого количества Алертов, которые непрерывно пишутся в лог и раздувают его (и как следствие постоянное обращение к харду замедляет все). Убрал алерты, но проблема осталась. Странно..

 

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

Возможно вы также успользуете ArrayResize() ?

 
чтобы начисто исключить RAM нужен такой эксперимент - максимально разгрузить, позакрывать все в т.ч. резидентов, и протестить
чтобы исключить глюки винды нужно чтобы реестр был без ошибок
чтобы исключить глюки МТ-4 (а что это скорость при переходе 2 Гб упала) нужно их поймать
общее наблюдение - советники с массивной обработкой модификацией ордеров работают заметно медленнее,
(можно сократить число модификаций внутри бара)
 
chief2000 >>:

Привет!

Написал вчера одного Советника, бежит на дневных свечах, всего около 800 сделок (>10 лет истории). Пока не было отложенных ордеров (которые периодически добавляются/удаляются) бежал шустро до победного. С отложенными, примерно 50% ~ 400 сделок проскакивает одним махом, а затем начинает тормозить. Сам МТ потребляет при этом всего около 10МБ памяти. Комп довольно сильный, так что дело не в железе. Все циклы связанны только с проверкой открытых ордеров.

Может кто-то сталкивался с подобными проблемами? Какие-нибудь идеи?

Спасибо!

Какая винда стоит?

 

Встречал замедление в случае если висит много ордеров.

тоесть тестер ослеживает много ордеров.

Включите визуализацию и посмотрите, может что-то не закрывается и остается висет?

За десять лет тестирования накапливается и тормозит.

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

Не думаю, что проблема из-за количества отработанных ордеров. 800 ордеров - очень мало.

У меня бывало на тестере по несколько тысяч отрабатывал за длительные сроки, отлично работает.

Все же я сколняюсть, что это таки какой-то из циклов.

Ведь ты же ордера закрываешь и удаляешь.

А закрываешь наверняка с проверкой по кол-ву открытых. Если есть ошибка при закрытии, то и получишь вечный цикл проверки кол-ва открытых.

Конечно же, все может быть иначе.

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

Тогда точно увидишь, что пошло не так, и ошибка выйдет на свет.

Или кидай сюда код с циклами.

Потри все расчеты, оставь только строки работы с одрерами.

Глядишь, общими силами найдем.

Удачи!

 

По непонятной причине больше недели не мог залогиниться и ответить..

Обнаружились следующие две причины:

1. Я использую комментарии (comments) с целью дебаггирования, если число строчек превышает пороговое

(не пытался выяснить точное количество) - скорость работы замедляется. Bug.

2. Скрипт построен из модулей, но не все из них используются все время (т.е. у меня есть шаблон с набором модулей,

на его основе я пишу новые Советники). То что не используется в данном конкретном Советнике я просто

комментировал следующим образом:

/*

модуль ...

*/

Если впоследствии я вводил какой-то модуль в работу, то часто раскомментировал его таким образом:

// /*

модуль ...

// */

С точки зрения mq4-редактора это законно. После удаления подобных комментариев Советник перестал тормозить.

Здесь опять-таки, есть какое-то пороговое количество закомментированных модулей, после которого начинается торможение.

.

Спасибо Всем!

 

Это, кстати, стоит кинуть в пожелания к mql5.

Реальные баги, которые стоит поправить (или может уже поправлены).

Т.е. я еще могу понять первую причину. Но с комментами в коде... надо бы поправить в mql5.

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