SeriousRacoon #: Почему в четвёрке это возможно и не просто возможно, но и работает быстро?
В четверке на самом деле сам терминал для каждого эксперта создает и обновляет фоновую копию/снапшот текущего чарта, чтобы робот потом мог по ней бегать без блокировок.
Преставьте себе, что перед вызовом OnTick происходит CopyRates всей истории в фоновой буфер робота. Конечно, с массой трюков для ускорения. В любом случае, это затратно по памяти и достаточно дорого. Обновление буфера добавляет латенси у реакции на OnTick.
Так как эти фоновые затраты идут вне контекста выполнения робота на MQL4, вам кажется, что скорость внутри MQL4 высока и бесплатна. Но удар по памяти и CPU все равно остается из-за расходов на фоновой буфер.
Причем учтите, то копируется только текущий чарт, что позволяет достаточно быстро работать iOpen/iHigh/iLow/iClose функциям на своем чарте. А вот доступ к другим таймфреймам и символам уже через Copy семантику, что выливается в синхронизированный доступ к базе истории как в пятерке.
Пятерка в этом отношении более честна и экономна:
Нет фоновых буферов и фоновой работы вне пределов MQL5
Экономнее расход памяти
Никто не добавляет задержек при реакции на OnTick
Так как пятерка имеет на порядок больше данных, то попытка делать и обновлять фоновые буферы просто убила бы систему.
В четверке на самом деле сам терминал для каждого эксперта создает и обновляет фоновую копию/снапшот текущего чарта, чтобы робот потом мог по ней бегать без блокировок.
Преставьте себе, что перед вызовом OnTick происходит CopyRates всей истории в фоновой буфер робота. Конечно, с массой трюков для ускорения. В любом случае, это затратно по памяти и достаточно дорого. Обновление буфера добавляет латенси у реакции на OnTick.
Так как эти фоновые затраты идут вне контекста выполнения робота на MQL4, вам кажется, что скорость внутри MQL4 высока и бесплатна. Но удар по памяти и CPU все равно остается из-за расходов на фоновой буфер.
Причем учтите, то копируется только текущий чарт, что позволяет достаточно быстро работать Open/High/Low/Close функциям. А вот доступ к другим таймфреймам и символам уже через Copy семантику, что выливается в синхронизированный доступ к базе истории как в пятерке.
Пятерка в этом отношении более честна и экономна:
Нет фоновых буферов и фоновой работы вне пределов MQL5
Экономнее расход памяти
Никто не добавляет задержек при реакции на OnTick
Так как пятерка имеет на порядок больше данных, то попытка делать и обновлять фоновые буферы просто убила бы систему.
Абсолютно уверен, что существует универсальное решение.
Во всяком случае уверен, что я бы его нашел.
Речь в том числе о функциях доступа к параметрам чарта ChartGet и событийной модели. Легко добиться максимального приоритета торговых функций. Потеря в несколько микросекунд ( пусть даже десятков микросекунд) на поддержание внутренних таблиц-массивов в актуальном состояние на каждом тике - вообще не критично, когда в результате получаем абсолютно нелагающую систему.
Тогда с каждым тиком буду запрашивать 1 элемент графика. Для того, что бы терминал продолжал обновлять этот график. Это позволит всегда получать данные без лишних задержек и приключений. Наверное...😄
Вроде ж логично - график то нужно поддерживать в актуальном состоянии (речь идет о "чужом" графике).
Ну и на 4ке тоже всегда поступаю как здесь. Оно точно работает, но может есть другие решения (не уступающие по надежности)?
И еще 1 вопрос возник по ходу. Если нужно скопировать заранее неизвестное количество элементов (что-то ищем), то нужно копировать сразу побольше, но одним разом?
То есть, мы например, копируем по 50 баров, пока ищем: скопировали 50 штук - не нашли, скопировали следующие 50 штук... Может ли быть такое, что между этими копированиями появится новый бар и сдвинет индексацию?
И еще 1 вопрос возник по ходу. Если нужно скопировать заранее неизвестное количество элементов (что-то ищем), то нужно копировать сразу побольше, но одним разом?
То есть, мы например, копируем по 50 баров, пока ищем: скопировали 50 штук - не нашли, скопировали следующие 50 штук... Может ли быть такое, что между этими копированиями появится новый бар и сдвинет индексацию?
Если ищете что-то существенное в широком диапазоне, то запрашивать 50 баров неразумно мало.
Конечно, между CopyXXX функциями теоретически может появиться новый бар при докачке истории.
Прямого чтения чартов без копирования не может быть принципиально.
Разве что доступ к каждому элементу обкладывать синхронизаторами доступа, что снизит скорость доступа в десятки и сотни раз.
Почему в четвёрке это возможно и не просто возможно, но и работает быстро?
В четверке на самом деле сам терминал для каждого эксперта создает и обновляет фоновую копию/снапшот текущего чарта, чтобы робот потом мог по ней бегать без блокировок.
Преставьте себе, что перед вызовом OnTick происходит CopyRates всей истории в фоновой буфер робота. Конечно, с массой трюков для ускорения. В любом случае, это затратно по памяти и достаточно дорого. Обновление буфера добавляет латенси у реакции на OnTick.
Так как эти фоновые затраты идут вне контекста выполнения робота на MQL4, вам кажется, что скорость внутри MQL4 высока и бесплатна. Но удар по памяти и CPU все равно остается из-за расходов на фоновой буфер.
Причем учтите, то копируется только текущий чарт, что позволяет достаточно быстро работать iOpen/iHigh/iLow/iClose функциям на своем чарте. А вот доступ к другим таймфреймам и символам уже через Copy семантику, что выливается в синхронизированный доступ к базе истории как в пятерке.
Пятерка в этом отношении более честна и экономна:
В четверке на самом деле сам терминал для каждого эксперта создает и обновляет фоновую копию/снапшот текущего чарта, чтобы робот потом мог по ней бегать без блокировок.
Преставьте себе, что перед вызовом OnTick происходит CopyRates всей истории в фоновой буфер робота. Конечно, с массой трюков для ускорения. В любом случае, это затратно по памяти и достаточно дорого. Обновление буфера добавляет латенси у реакции на OnTick.
Так как эти фоновые затраты идут вне контекста выполнения робота на MQL4, вам кажется, что скорость внутри MQL4 высока и бесплатна. Но удар по памяти и CPU все равно остается из-за расходов на фоновой буфер.
Причем учтите, то копируется только текущий чарт, что позволяет достаточно быстро работать Open/High/Low/Close функциям. А вот доступ к другим таймфреймам и символам уже через Copy семантику, что выливается в синхронизированный доступ к базе истории как в пятерке.
Пятерка в этом отношении более честна и экономна:
Опубликуйте свое решение.
Да, в процессе
Особенно проработайте вопрос доступа к чужим чартам, пожалуйста.
И чтобы кеш попадания были от 70%, чтобы не оказались массовыми кейсы, когда кеши остаются неиспользованными.
Попробую еще раз поинтересоваться мнением высококвалифицированных господ.
На сколько вменяемо такое решение?
Тогда с каждым тиком буду запрашивать 1 элемент графика. Для того, что бы терминал продолжал обновлять этот график. Это позволит всегда получать данные без лишних задержек и приключений. Наверное...😄
Вроде ж логично - график то нужно поддерживать в актуальном состоянии (речь идет о "чужом" графике).
Ну и на 4ке тоже всегда поступаю как здесь. Оно точно работает, но может есть другие решения (не уступающие по надежности)?
И еще 1 вопрос возник по ходу. Если нужно скопировать заранее неизвестное количество элементов (что-то ищем), то нужно копировать сразу побольше, но одним разом?
То есть, мы например, копируем по 50 баров, пока ищем: скопировали 50 штук - не нашли, скопировали следующие 50 штук...
Может ли быть такое, что между этими копированиями появится новый бар и сдвинет индексацию?
Попробую еще раз поинтересоваться мнением высококвалифицированных господ.
На сколько вменяемо такое решение?
Вроде ж логично - график то нужно поддерживать в актуальном состоянии (речь идет о "чужом" графике).
Ну и на 4ке тоже всегда поступаю как здесь. Оно точно работает, но может есть другие решения (не уступающие по надежности)?
И еще 1 вопрос возник по ходу. Если нужно скопировать заранее неизвестное количество элементов (что-то ищем), то нужно копировать сразу побольше, но одним разом?
То есть, мы например, копируем по 50 баров, пока ищем: скопировали 50 штук - не нашли, скопировали следующие 50 штук...
Может ли быть такое, что между этими копированиями появится новый бар и сдвинет индексацию?
Если ищете что-то существенное в широком диапазоне, то запрашивать 50 баров неразумно мало.
Конечно, между CopyXXX функциями теоретически может появиться новый бар при докачке истории.