![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В боевых роботах оставил только 0-INT_MAX-вариант. Тормоза прекратил замечать.
Что вы потом с этой историей делаете?
Я конечно могу менять субсчет каждый месяц, чтобы ограничивать историю ордеров какой-нибудь сотней тысяч, но это не выход :)
Что вы потом с этой историей делаете?
Я конечно могу менять субсчет каждый месяц, чтобы ограничивать историю ордеров какой-нибудь сотней тысяч, но это не выход :)
На данный момент вижу, что в 99% случаев нужно использовать только HistorySelect(0, INT_MAX). Остальные варианты стараться не использовать.
Наверное, достаточно не двигать начало кэша, то есть всегда запрашивать с одинаковой даты (а будет ли она равна 0 — не важно).
Нужно проверить.
Наверное, достаточно не двигать начало кэша, то есть всегда запрашивать с одинаковой даты (а будет ли она равна 0 — не важно).
Нужно проверить.
Возможно. Тестером тяжело долго быть.
Результат.
На каждом тике проблема.
ЗЫ Установил Win10, LatencyMon показывает, что все отлично.
Шлангом наивным зачем прикидываться?
Что раньше, что сейчас - пытаетесь показать на ровном месте, что убийство кеша - это не норма. Вы сами виноваты, что убиваете кеш на большой истории. И это исключительно ваша проблема специально подстраивать from позицию. Можно найти много возможностей убивать/отравлять кучу кешей в MQL5 окружении.
Помогать вам не будем - в любом языке программирования есть громадное количество вариантов выстрелить себе в ногу и голову.
К вам бы относились нормально, если бы вы явно указывали "смотрите - это я специально отравляю кеш и стреляю в себя".Наверное, достаточно не двигать начало кэша, то есть всегда запрашивать с одинаковой даты (а будет ли она равна 0 — не важно).
Нужно проверить.
Именно это я прямо и описывал.
Если делаете выборку по дате, не пытайтесь на каждом запросе устраивать разную from выборку. Ну и с to датой старайтесь выставлять ее вперед.
Мы специально конктролируем to позицию, автоматически сводя ее к INT_MAX, если она превышает или равна текущей дате.
Что раньше, что сейчас - пытаетесь показать на ровном месте, что убийство кеша - это не норма. Вы сами виноваты, что убиваете кеш на большой истории. И это исключительно ваша проблема специально подстраивать from позицию. Можно найти много возможностей убивать/отравлять кучу кешей в MQL5 окружении.
Одна библиотека использует HistorySelect от TimeCurrent. Другая - от нуля. Какого хрена должен лезть в потроха библиотек, чтобы выяснить, что они не совместимы друг с другом для производительной работы?
Лаконичный пример - это выяснение причины, почему безобидные библиотеки могут мешать друг другу. Включайте, наконец, критическое мышление.
Одна библиотека использует HistorySelect от TimeCurrent. Другая - от нуля. Какого хрена должен лезть в потроха библиотек, чтобы выяснить, что они не совместимы друг с другом для производительной работы?
Лаконичный пример - это выяснение причины, почему безобидные библиотеки могут мешать друг другу. Включайте, наконец, критическое мышление.
Такого хрена, что это лично ваша проблема, что вы пользуетесь библиотеками и отключаете голову.
Такого хрена, что это лично ваша проблема, что вы пользуетесь библиотеками и отключаете голову.
Давайте-ка сами все с нуля на асме идите писать. Оказывается, нормально, когда каждая из библиотек летает по отдельности. Но стоит их начать использовать обе сразу, как начинаются тормоза.
Мы с успехом репортили ошибки в Microsoft, но никогда не писали и не обвиняли их, что есть примерно N миллионов возможностей убиться об их API.
Тем более, используя при этом чужие библиотеки.