Ограничение кеша индикатора.
Есть два пункта по этой проблеме.
1) Полностью согласен с не оптимальной и тупиковой концепцией: https://www.mql5.com/ru/forum/3302
2) Можно поступить как я: https://www.mql5.com/ru/articles/247, он полностью решает все проблемы (и с отрисовкой тоже), кроме автоматического выделения памяти для графика...
- www.mql5.com
То есть, вопрос сводится к тому, чтобы из MQL5 задавать желаемое ограничение глубины индикатора?
Если в кеше нет данных, то кеш открывается на указанную глубину, но если кто-то другой (например, чарт) запросит больше, то кеш перестроится и пересчитается заново. Так?
Есть два пункта по этой проблеме.
1) Полностью согласен с не оптимальной и тупиковой концепцией: https://www.mql5.com/ru/forum/3302
2) Можно поступить как я: https://www.mql5.com/ru/articles/247, он полностью решает все проблемы (и с отрисовкой тоже), кроме автоматического выделения памяти для графика...
Чтоб не запрашивать 4 000 000 данных я выделил динамичные массивы получил данные напрямую (минуя индикаторные тайм-прайсы, чтоб даже обращения к ним не было) но это не помогло, всё равно индикаторы тянут всю историю себе в кеш. Это я отследил через выделяемую память в диспетчере задачь.
Плюс время загрузки индикаторов иногда достигает 20 мин (те само кеширование не оптимально), хотя расчёт того же кода на скрипте происходит в считанные секунды.
Отсюда вытекают две задачи для разработчиков которые (имхо) помогут программистам реализовывать всё что угодно:
1 Программное ограничение кеша (управление выделяемой под индикатор памятью).
2 Возможность передавать массивы в уже запущенный индикатор (этот пункт вытекает из того что индикатор всё таки средство визуализации, а не только параллельных расчётов).
То есть, вопрос сводится к тому, чтобы из MQL5 задавать желаемое ограничение глубины индикатора?
Если в кеше нет данных, то кеш открывается на указанную глубину, но если кто-то другой (например, чарт) запросит больше, то кеш перестроится и пересчитается заново. Так?
Можно оставить умолчательную возможность динамично выделять кеш, и жёсткую обрезанную программно если программист того желает.
ЗЫ Раз уж мы привлекли ваше внимание, ответьте на вопрос: откуда индикатор берёт данные из истории или из чарта?
Просто наблюдал такую картину что индикаторы запущенные по символу не своего чарта часто вообще не могут получить историю (или она грузится настолько долго что это не приемлемо), хотя рядом висит открытый требуемый чарт.
В то время, когда я изучал поведение MetaTrader, незаполненные буферы индикатора никак не влияли на выделяемую память.
Влиял только открытый график с несколько миллионами баров.
- www.mql5.com
Чтоб не запрашивать 4 000 000 данных я выделил динамичные массивы получил данные напрямую (минуя индикаторные тайм-прайсы, чтоб даже обращения к ним не было) но это не помогло, всё равно индикаторы тянут всю историю себе в кеш. Это я отследил через выделяемую память в диспетчере задачь.
Плюс время загрузки индикаторов иногда достигает 20 мин (те само кеширование не оптимально), хотя расчёт того же кода на скрипте происходит в считанные секунды.
Вот это совершенно непонятно. Можете подробнее рассказать?
Отсюда вытекают две задачи для разработчиков которые (имхо) помогут программистам реализовывать всё что угодно:
1 Программное ограничение кеша (управление выделяемой под индикатор памятью).
Скорее всего вот этот вариант сможет помочь. Можно рабочий максбар выставить в 100 000, а из индикаторов по необходимости запрашивать бОльшую глубину. Но это только предположения - в реализации могут вылезти серьезные проблемы.
Ну и на x64 пора массово переходить - там сразу решается огромный пласт проблем.
ЗЫ Раз уж мы привлекли ваше внимание, ответьте на вопрос: откуда индикатор берёт данные из истории или из чарта?
Из исторического кеша.
Просто наблюдал такую картину что индикаторы запущенные по символу не своего чарта часто вообще не могут получить историю (или она грузится настолько долго что это не приемлемо), хотя рядом висит открытый требуемый чарт.
Из исторического кеша.
Ок, как отловлю стабильно повторяющуюся ситуацию обращусь.
Взгляните пожалуйста на общую концепцию реализации одного проэкта,
и как разработчик знающий все нюансы МТ5 скажите почему это должно работать плохо.
Требуется визуализировать на разных чартах по требованию пользователя данные баланса и еквити (общего либо по каждому символу).
Для чего пишим индикатор А1 который запуская у себя в ините индикаторы А2 и А3 высчитывает на их данных значения для требуемого ТФ.
Данные А2 и А3 строятся по M1. А2 стоится на основе разносимвольных индикаторов А3.
Таким образом в ините советника запускаем А2, он кешируется в МТ(тем самым кешируя все нужные A3) после чего открываем нужные чарты и прикрепляем к необходимым экземпляр А1 (с нужным символом). Все экземпляры А1 отличаются тк А3 у всех вызывается с родного символа.
В А1 по команде (через событие) делаем отрисовку либо пересчитанных на текущий ТФ данных А2 либо А3.
и как разработчик знающий все нюансы МТ5 скажите почему это должно работать плохо.
Навскидку ответить не смогу (кроме общих проблем со своевременной готовностью всех связанных данных), так как не описано в каком месте у Вас появилась проблема.
Лучше с готовым примером и описанием проблемы напрямую обратиться в сервисдеск к разработчикам.
- www.mql5.com
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Обращаюсь к разработчикам MQ.
Обдумал много раз прежде чем написать, чё то вы ребята не здоровое наоптимизировали с индикаторами.
Есть простая задача, нужно на исторических данных сделать расчёт по разным валютам. Ограничивать пользователя программист не может поэтому всё должно работать на Unlimited. Да и может возникнуть ситуация когда нужно пара сотен данных но в начале истории. Поэтому ограничения количества баров в окне точно не катят.
Расчёт нужен по всем инструментам по которым велась торговля. В частном случае это 12 инструментов.
Расчёт нужен по М1.
Трех месячная история М1 это около 80 000 баров. Время и прайсы это значит умножить на 5. В дублях значит ещё на 8 байт.
Итого нужно получить 36.6211 Mb, вроде бы нормальная задача.
Но вот нет никакой возможности ограничить автоматическую загрузку данных в кеш индикатора. В результате индикатор тянет ~ 4 000 000 баров по каждому запрашиваемому инструменту. Не сложный подсчёт и получаем 1.7524 Gb совершенно не используемых данных.
Отсюда вопрос: где тут экономия?, да совсем забыл сказать что расчёт нужен единожды дальше пользуем расчитанные данные.
Всё можно было бы порешать через однократный расчёт в советнике, но как передать индикатору на отрисовку?
Остаётся только старым методом, рисовывать массивы тренд-линиями, но тут экономией и не пахнет. 80 000 объектов по каждому инструменту это уже перебор.