Ошибки, баги, вопросы - страница 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 рублей.
Ренат, нулевым пунктом - большое спасибо за внимание к теме и конструктивный ответ!
Далее.
1. про х64
Renat:
Более правильный вариант - переход на x64.
...
Конечно же, если кто-то будет вызывать сотни индикаторов в режиме сканирования рынка без их выгрузки, то им прямая дорога исключительно в 64 битную версию + установка дополнительной памяти.
Сейчас странно заниматься массивными тестами, сидя на x32. Любой приличный x64 компьютер с 16 Гб памяти (без фанатизма по видеокартам и мониторам) можно купить за 15 000 рублей.
Переход на x64 - по любому правильное направление действий. Но. Одно другое не исключает. Даже мои 16гиг (их есть у меня) мне не хочется транжирить на ненужные мне по факту данные. У меня есть ещё чему параллельно работать надо - MSVS, Матлаб, и т.п., на которых я тоже объёмистые задачи хочу считать. Я рад, что вы это понимаете и готовы искать пути экономии.
2. Про фиксированное начало истории:
Renat:
Нам самим хочется уменьшить потребление ресурсов. Возможно, решением может быть некая функция IndicatorMaxDepth(uint len), которая будет действовать только на индикаторы, создаваемые в этом эксперте.
Но проблема в том, что при тестировании буферы индикаторов в режиме накопления будут расти вместе с историей и экономии не получится.
Полностью (почти) согласен. Оговорка: Во многих случаях оптимизация проводится на небольшом куске последней истории. В этом случае экономия может быть и весьма существенная. И всё же вариант рассматриваю как относительно рабочий - особенно если у вас есть хорошие наработки или прикидки по реализации. Мне, например, вариант представляется не вполне полноценным - трудозатрат много, а результат не радикален. Половинчатое решение.
3. А вот он и язь! :
Renat:
Подрезать в рилтайме историю индикатора, поддерживая заданную глубину чревато красивыми глюками и прямым сносом крыши у программистов, которые считают/привыкли к синхронности баров чарта и буфера индикатора.
Нет ! , не чревато - если бары чарта ведут себя таким же образом - синхронно. Другими словами - если кольцевые буферы (пусть даже разные по размеру) всегда (насильственно) используют флаг AsSeries - массовых неприятностей у юзера не ожидается.
// В этом случае удобно будет сделать все предоставляемые юзеру исторические буферы - индикаторными (т.е. кольцевыми, с AsSeries=true).
В этом варианте:
(1) есть внутренне представление индикаторных и ценовых массивов (на вашей стороне) : индексация слева направо (AsSeries==false), размеры юзера не касаются, да и вообще "вход воспрещён".
И (2) есть сторона юзера - все буферы кольцевые (в реализации. юзер видит виртуальный линейный массив), индексация справа налево (AsSeries==true) и размер задан юзером.
Какие здесь сносы юзерской крыши? Никаких. При выходе за заданный диапазон - стандартная реакция Array out of range.
Трудности (немалые, если честно) только у вас. Но! Учитывая универсальность схемы - напрячься придётся только один раз. И пофиксить все "красивые глюки" в зародыше, при отладке беты. После чего - всеобщее счастье и очень экономная конструкция.
Мы проведем ревизию кеша индикаторов, у которого сейчас работает принцип максимальной эффективности против принципа экономии памяти. Индикаторы, от которых отказались, попробуем сразу же выгружать, а не держать некоторое время в памяти, как делается сейчас. Это даст возможность вызывать сотни индикаторов подряд с прямой выгрузкой через IndicatorRelease.