Ошибки, баги, вопросы - страница 672
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А баров в окне сколько стоит?
Проблема в том, что при переключении ТФ не освобождается память в терминале. Запустите диспетчер задач, бросьте индикатор на график и посмотрите как растет память. Петерь переключитесь на другой ТФ. Вы увидите, как память опять начнет расти. Хотя по логике при переключении на другой ТФ, данные предыдущего ТФ должны выгружаться из памяти. Так как данные с предыдущих ТФ не уничтожаются, память растет до перепелнения и выдачи ошибки. Если Вы уберете свой индикатор с графика, то увидите, что через определенный промежуток времени память очистится. Но во время работы индикатора она не очищается.
Мое мнение: Решение данной проблемы - СервисДек.
Спасибо, буду перед переключением ТФ сначала удалять индикатор. К тому же я сократил макс.кол-во баров в окне с 2000000 до 1000000 видимо MetaDriver хочет мне это сказать.
Пока вроде работает.
Спасибо, буду перед переключением ТФ сначала удалять индикатор. К тому же я сократил макс.кол-во баров в окне с 2000000 до 1000000 видимо MetaDriver хочет мне это сказать.
Пока вроде работает.
Зачем тебе мульён?? Мне хватает 100 000 (сто тысяч). Именно на это я намекал.
Это никак не ограничивает тестирование на любую глубину.
Это ограничивает только (1) отображение в окнах (2) размеры индикаторных буферов.
Я давно и осознанно ограничил "видимую историю". Результат - с памятью у меня проблем нет.
Зачем тебе мульён?? Мне хватает 100 000 (сто тысяч). Именно на это я намекал.
Это никак не ограничивает тестирование на любую глубину.
Это ограничивает только (1) отображение в окнах (2) размеры индикаторных буферов.
Я давно и осознанно ограничил "видимую историю". Результат - с памятью у меня проблем нет.
Да, спасибо, я еще больше органичу, чтобы не было проблем с памятью, а то на InstaForex я вообще 108 пар собираюсь использовать.
Вапче тема ещё та. Я ещё на заре МТ5 вопил, что нужно бы во всех индикаторах ввести новый стандартный параметр - количество баров для расчёта.
Иначе получается единственный ограничитель - TERMINAL_MAXBARS. Это неприемлемо для экспертов, анализирующих множество инструментов в реальном времени при помощи индикаторов. Мне в экспертах чаще всего (99%) нужно строго конкретное количество последних баров И ВСЁ. Всё лишнее мне поперёк горла. Разумеется не только мне...
Было проигнорировано. В результате - перенос подобных расчётов в код эксперта.
Ах да! И появление множества самописных заплаток. Даже статьи вумные написаны и опубликованы, типа:
Уменьшаем расход памяти на вспомогательные индикаторы
Реализация индикаторов в виде классов на примере Zigzag и ATR
...
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
В общем, ничего не меняется. Просьбы о введении возможности средствами MQL5 ограничивать размер индикаторных буферов - отклоняются, а если твоя программа начинает потреблять огромное количество памяти из-за множества используемых индикаторных буферов - то это тут же называется "ошибкой программиста".
"Мне в экспертах чаще всего (99%) нужно строго конкретное количество последних баров И ВСЁ. Всё лишнее мне поперёк горла. Разумеется не только мне..." (с)
2. Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
3. Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
1. Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
1. Я так и сделал. И всё же это некомфортный компромисс. В идеале, если полностью отвлечься от проблем разработки (чисто как юзеру) мне хотелось бы иметь выбор при задании длины расчёта. Для чарта - во всю длину (притом что не всегда, есть серьёзные и немалые исключения), для экспертов - ровно сколько нужно.
2. Давайте всё таки подумаем. Как разработчик, я понимаю сложности и одновременно ограничения такого (с указанием длины расчёта) подхода, и всё же расход памяти - это тоже моя проблема и она упорно не хочет отступать на вторые роли. У меня есть конкретное предложение-решение - считать расчётный период (назовём это так) равноправным параметром-не-хуже-других. Тогда два индикатора со всеми совпадающими параметрами, но с другим рассчётным периодом - это просто два разных индикатора. Да, чисто теоретически есть глупые варианты использования, способные привести к дополнительным расходам (если пользователь будет плодить расчётные периоды), но на практике это маловероятно. Если кто-то захочет погулять по этим граблям - сам виноват. Примерно так как сейчас ВСЕ пользователи виноваты в том, "открыли слишком много индикаторов и не позаботились о уменьшении TERMINAL_MAXBARS".
3. Я знаю. Мне известно что при расчёте, например, EMA используются все бары с начала времён. Но мне так же известно что в стохастике, RSI, и огромном (преобладающем) количестве других индикаторов расчёт производится на органиченную длину. И это знание вполне позволяет мне гибко подойти к выбору расчётного периода (MaxBar). Только дайте выбор.
Примерно так как сейчас ВСЕ пользователи виноваты в том, "открыли слишком много индикаторов и не позаботились о уменьшении TERMINAL_MAXBARS".
Ага, особенно в условиях чемпионата, когда повлиять на размер TERMINAL_MAXBARS ты вообще не в состоянии.
1. Я так и сделал. И всё же это некомфортный компромисс. В идеале, если полностью отвлечься от проблем разработки (чисто как юзеру) мне хотелось бы иметь выбор при задании длины расчёта. Для чарта - во всю длину (притом что не всегда, есть серьёзные и немалые исключения), для экспертов - ровно сколько нужно.
2. Давайте всё таки подумаем. Как разработчик, я понимаю сложности и одновременно ограничения такого (с указанием длины расчёта) подхода, и всё же расход памяти - это тоже моя проблема и она упорно не хочет отступать на вторые роли. У меня есть конкретное предложение-решение - считать расчётный период (назовём это так) равноправным параметром-не-хуже-других. Тогда два индикатора со всеми совпадающими параметрами, но с другим рассчётным периодом - это просто два разных индикатора. Да, чисто теоретически есть глупые варианты использования, способные привести к дополнительным расходам (если пользователь будет плодить расчётные периоды), но на практике это маловероятно. Если кто-то захочет погулять по этим граблям - сам виноват. Примерно так как сейчас ВСЕ пользователи виноваты в том, "открыли слишком много индикаторов и не позаботились о уменьшении TERMINAL_MAXBARS".
3. Я знаю. Мне известно что при расчёте, например, EMA используются все бары с начала времён. Но мне так же известно что в стохастике, RSI, и огромном (преобладающем) количестве других индикаторов расчёт производится на органиченную длину. И это знание вполне позволяет мне гибко подойти к выбору расчётного периода (MaxBar). Только дайте выбор.
Мысль понятна.
Нам самим хочется уменьшить потребление ресурсов. Возможно, решением может быть некая функция IndicatorMaxDepth(uint len), которая будет действовать только на индикаторы, создаваемые в этом эксперте.
Но проблема в том, что при тестировании буферы индикаторов в режиме накопления будут расти вместе с историей и экономии не получится. Подрезать в рилтайме историю индикатора, поддерживая заданную глубину чревато красивыми глюками и прямым сносом крыши у программистов, которые считают/привыкли к синхронности баров чарта и буфера индикатора.
Более правильный вариант - переход на x64.
Мы проведем ревизию кеша индикаторов, у которого сейчас работает принцип максимальной эффективности против принципа экономии памяти. Индикаторы, от которых отказались, попробуем сразу же выгружать, а не держать некоторое время в памяти, как делается сейчас. Это даст возможность вызывать сотни индикаторов подряд с прямой выгрузкой через IndicatorRelease.
Конечно же, если кто-то будет вызывать сотни индикаторов в режиме сканирования рынка без их выгрузки, то им прямая дорога исключительно в 64 битную версию + установка дополнительной памяти.
Сейчас странно заниматься массивными тестами, сидя на x32. Любой приличный x64 компьютер с 16 Гб памяти (без фанатизма по видеокартам и мониторам) можно купить за 15 000 рублей.