2019.01.0917:14:06.682 indicator is too slow, 30420 ms. rewrite the indicator, please
2019.01.0917:21:01.051 indicator is too slow, 30561 ms. rewrite the indicator, please
2019.01.0917:27:36.834 indicator is too slow, 30467 ms. rewrite the indicator, please
2019.01.0917:34:12.278 indicator is too slow, 30467 ms. rewrite the indicator, please
2019.01.0917:40:48.481 indicator is too slow, 30514 ms. rewrite the indicator, please
2019.01.0917:47:23.671 indicator is too slow, 30343 ms. rewrite the indicator, please
2019.01.0917:53:58.584 indicator is too slow, 30436 ms. rewrite the indicator, please
вы 8 (!!) раз на тик вызываете ChartRedraw, конечно оно тормозит. Я бы на месте терминала тоже матерился :-)
да и алгоритм тоже как-бы помягче сказать..не быстрый :-)
методы лечения:
- считать пооптимальнее (всё можно в один проход посчитать). Опционально
- создавать объекты заранее и не проверять их наличие на каждом чихе. Можно пересоздавать поймав CHARTOBJECT_DELETE
- сохранять прежние значения и лезть в объекты только если поменялись данные
- ChartRedraw вызывать только при крайней необходимости. Он вообще по большому счёту там ненужен. Вы же не анимацию какую делаете - он сам перерисует.
В некоторых случаях я готов согласиться с неоптимальностью кода.
Давайте по-порядку:
1. Считать пооптимальнее... это как? Если внимательней посмотреть код, то можно понять, что закрытые позиции "сегодня" в следующие периоды не пересчитываются. Считать пореже??? может быть, но это не тормозит.
2. Наверное ДА, но я оговорился в самом начале, что размещать этот примитивный код в CodeBase не собирался. Люди попросили, я сделал побыстрому... работает и ладно.
3. Что затратней получится, проверка прежнего значения или повторное занесение этого значения в OBJPROP_TEXT без проверки что в нём уже есть, вопрос остаётся открытым без многоразовых замеров скорости. А оно мне надо?
4. Где-то в документации есть подобные оговорки??? Наверное он и не нужен, но при отладке чтобы увидеть место расположения было это вписано, так и осталось. НО!!! Если оставить только проверку наличия объекта и исключить ChartRedraw() то тормоза остаются.
И плюс ко всему, тогда когда это было написано тормозов не было!!! Тормоза появились после обновления.
Добавлено: Ещё есть проблема создания объектов в ините в том, что никто не гарантирует последовательность выполнения OnInit и OnDeinit
Вполне вероятно, что сначала выполнится OnInit при переключении периода графика, а потом OnDeinit и удалит все объекты. Выходит что надо постоянно контролировать случайное удаление. А это дополнительные затраты и чаще всего бесполезные.
Ещё есть проблема создания объектов в ините в том, что никто не гарантирует последовательность выполнения OnInit и OnDeinit
Вполне вероятно, что сначала выполнится OnInit при переключении периода графика, а потом OnDeinit и удалит все объекты. Выходит что надо постоянно контролировать случайное удаление. А это дополнительные затраты и чаще всего бесполезные.
Если в MT изменить таймфрейм или имя символа чарта, то все индикаторы на чарте выгрузятся с чарта и загрузятся на него снова. При этом, в отличие от MT4, в MT5 последовательность выгрузиться/загрузиться не определена из-за особенности внутренней архитектуры. Данное обстоятельство иногда вызывает не сразу очевидные проблемы, связанные с тем, что...
Но без понимания я не использую чужой код. Это раз.
Понять что там написано я смогу лет через... столько не живут. Это два.
И три, неужели такой пустяковый код как в моём примере заслуживает такого сложного кода??? Да избавь Бог...
Создание объекта поверх уже имеющегося вызывает ошибку, но нигде это не регистрируется. Да проще убрать эту проверку и все дела. И ещё вариант удаление объектов сделать по условию reason == REASON_REMOVE и больше не при каких.
Простите, но я не просил научить меня как обойти эту проблему. Я всего-лишь прошу разработчиков обратить внимание на проблему в работе терминала.
вы 8 (!!) раз на тик вызываете ChartRedraw, конечно оно тормозит. Я бы на месте терминала тоже матерился :-)
да и алгоритм тоже как-бы помягче сказать..не быстрый :-)
методы лечения:
- считать пооптимальнее (всё можно в один проход посчитать). Опционально
- создавать объекты заранее и не проверять их наличие на каждом чихе. Можно пересоздавать поймав CHARTOBJECT_DELETE
- сохранять прежние значения и лезть в объекты только если поменялись данные
- ChartRedraw вызывать только при крайней необходимости. Он вообще по большому счёту там ненужен. Вы же не анимацию какую делаете - он сам перерисует.
Вот у меня это в индикаторе тормозит терминал
А без ChartRedraw таймер не обновляется, а с ним тупит.
Какое решение?
Нет. Причина найдена. Профилировщик не врёт.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Новая версия платформы MetaTrader 5 build 1930: Плавающие окна графиков и .Net библиотеки в MQL5
fxsaber, 2019.01.09 16:08
ЗЫ Лог работы индикатора на одном пустом чарте.
На Терминале никаких действий не совершалось.
вы 8 (!!) раз на тик вызываете ChartRedraw, конечно оно тормозит. Я бы на месте терминала тоже матерился :-)
да и алгоритм тоже как-бы помягче сказать..не быстрый :-)
методы лечения:
- считать пооптимальнее (всё можно в один проход посчитать). Опционально
- создавать объекты заранее и не проверять их наличие на каждом чихе. Можно пересоздавать поймав CHARTOBJECT_DELETE
- сохранять прежние значения и лезть в объекты только если поменялись данные
- ChartRedraw вызывать только при крайней необходимости. Он вообще по большому счёту там ненужен. Вы же не анимацию какую делаете - он сам перерисует.
В некоторых случаях я готов согласиться с неоптимальностью кода.
Давайте по-порядку:
1. Считать пооптимальнее... это как? Если внимательней посмотреть код, то можно понять, что закрытые позиции "сегодня" в следующие периоды не пересчитываются. Считать пореже??? может быть, но это не тормозит.
2. Наверное ДА, но я оговорился в самом начале, что размещать этот примитивный код в CodeBase не собирался. Люди попросили, я сделал побыстрому... работает и ладно.
3. Что затратней получится, проверка прежнего значения или повторное занесение этого значения в OBJPROP_TEXT без проверки что в нём уже есть, вопрос остаётся открытым без многоразовых замеров скорости. А оно мне надо?
4. Где-то в документации есть подобные оговорки??? Наверное он и не нужен, но при отладке чтобы увидеть место расположения было это вписано, так и осталось. НО!!! Если оставить только проверку наличия объекта и исключить ChartRedraw() то тормоза остаются.
И плюс ко всему, тогда когда это было написано тормозов не было!!! Тормоза появились после обновления.
Добавлено: Ещё есть проблема создания объектов в ините в том, что никто не гарантирует последовательность выполнения OnInit и OnDeinit
Вполне вероятно, что сначала выполнится OnInit при переключении периода графика, а потом OnDeinit и удалит все объекты. Выходит что надо постоянно контролировать случайное удаление. А это дополнительные затраты и чаще всего бесполезные.
Увы... Чтобы вас понять надо прочесть ещё десятка два страниц.
Ещё есть проблема создания объектов в ините в том, что никто не гарантирует последовательность выполнения OnInit и OnDeinit
Вполне вероятно, что сначала выполнится OnInit при переключении периода графика, а потом OnDeinit и удалит все объекты. Выходит что надо постоянно контролировать случайное удаление. А это дополнительные затраты и чаще всего бесполезные.
Эта проблема решается прописыванием одной строки.
Эта проблема решается прописыванием одной строки.
Ещё раз, большое откровенное спасибо.
Но без понимания я не использую чужой код. Это раз.
Понять что там написано я смогу лет через... столько не живут. Это два.
И три, неужели такой пустяковый код как в моём примере заслуживает такого сложного кода??? Да избавь Бог...
Создание объекта поверх уже имеющегося вызывает ошибку, но нигде это не регистрируется. Да проще убрать эту проверку и все дела. И ещё вариант удаление объектов сделать по условию reason == REASON_REMOVE и больше не при каких.
Простите, но я не просил научить меня как обойти эту проблему. Я всего-лишь прошу разработчиков обратить внимание на проблему в работе терминала.
неужели такой пустяковый код как в моём примере заслуживает такого сложного кода???
mqh универсальная - для любых индикаторов.
Простите, но я не просил научить меня как обойти эту проблему. Я всего-лишь прошу разработчиков обратить внимание на проблему в работе терминала.
Воспроизводимый короткий код проблемы показал.
mqh универсальная - для любых индикаторов.
Воспроизводимый короткий код проблемы показал.
Да, уже видел.
Что именно убрали, ObjectFind и ChartRedraw?
Какая именно тупила, или обе?
Так не проверял, но профилировщик не врёт.
Убрал эти две строки и всё затикало как положено.
Видимо разработчикам надо обратить на это внимание.
Да, видимо. И еще на то, что сообщение об ошибке выдал МQL4, а Вы использовали МТ5.
Но если ПОЛНОСТЬЮ процитировать примечание, то можно заметить и такую оговорку
Но в данном случае количество объектов назвать "большим" как-то язык не поворачивается.Объекты только часть того, что есть на графике. А синхронизируется ВСЕ