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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

/*

модуль ...

*/

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

// /*

модуль ...

// */

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

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

.

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

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

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

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