MT5 и скорость в боевом исполнении - страница 17
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Учтите, что HistorySelect делает физический снепшот выбранной истории в локальный кеш эксперта, чтобы можно было без боязни их перебирать. Без этого можно получить очень неприятные эффекты, так как история счета обновляется/синхронизируется асинхронно. Это не говоря уже о том, что пользователь сам вручную может из интерфейса поменять глубину истории.
Поэтому и такие расходы на копирование. Тем более, если специально заниматься одновременным принудительным копированием этой истории в кеш из множества потоков.
Мы уже многое оптимизировали в операциях выборок и сейчас думаем над оптимальным обновлением кеша, когда в реальности 99% выборок будут полностью бесполезными и пропускаться по факту.
То есть, если не будете специально рандомизировать пределы выборок, то кеш будет показывать попадания, близкие к 100%.
Скорее всего на следующей неделе уже будет эффективное решение.
Учтите, что HistorySelect делает физический снепшот выбранной истории в локальный кеш эксперта, чтобы можно было без боязни их перебирать. Без этого можно получить очень неприятные эффекты, так как история счета обновляется/синхронизируется асинхронно. Это не говоря уже о том, что пользователь сам вручную может из интерфейса поменять глубину истории.
Есть таблица ордеров и таблица сделок. Зачем делать физические снепы, когда достаточно знать четыре индекса на момент вызова HistorySelect?
Поэтому и такие расходы на копирование. Тем более, если специально заниматься одновременным принудительным копированием этой истории в кеш из множества потоков.
Мы уже многое оптимизировали в операциях выборок и сейчас думаем над оптимальным обновлением кеша, когда в реальности 99% выборок будут полностью бесполезными и пропускаться по факту.
То есть, если не будете специально рандомизировать пределы выборок, то кеш будет показывать попадания, близкие к 100%.
Скорее всего на следующей неделе уже будет эффективное решение.
HistoryDealSelect и HistoryOrderSelect сейчас уничтожают соответствующие выборки. Почему нет, как в MT4, доступа к обеим таблицам по индексам? Вводите же новый функционал.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
fxsaber, 2020.08.20 11:28
Новые штатные функции.Индексы напрашиваются. Совсем непонятно, почему через одно место нужно узнавать количество сделок на счете.
И эти таблицы могут в любой момент измениться. Как и отдельные записи в них.
Никто не может гарантировать их неизменность из-за асинхронных операций, процессов синхронизации и режимов глубины, выставляемых пользователями вручную.
Как я писал выше, мы применим методы интеллектуального кеширования, что снизит до нуля расходых на Select функции. Если, конечно, не будете специально рандомизировать пределы выборок. Последнюю дату можно менять и она не будет инвалидировать кеш, если она всегда будет в будущем/послднем времени. Последние транзакции будут экономно добавляться в кеш.
В МТ4 работает так же, просто создание кеша скрыто. На каждом OnTick/OnStart МТ4 терминал автоматически и экономно создает снепшот рыночного окружения для каждого эксперта.
Поэтому вы не можете оценить истинных задержек на подготовке данных из MQL4 кода. К счастью, в МТ4 данных мало и все просто.
В МТ5 мы отказались от затрат на автоматическое создание рыночного окружения, чтобы снизить задержки и не делать лишней работы. Вместо этого мы дали полный контроль над расходами разработчикам роботов, которые могут запрашивать ровно то, что им нужно.
Обратите внимание, что обьем рыночного окружения в МТ5 огромен по сравнению с МТ4 - его попросту нельзя реплицировать.
Своими тестами вы воспользовались одной из таких затратных выборок.
Мы это исправим - это в наших интересах.
И эти таблицы могут в любой момент измениться. Как и отдельные записи в них.
Никто не может гарантировать их неизменность из-за асинхронных операций, процессов синхронизации и режимов глубины, выставляемых пользователями вручную.
Хотите сказать, что перед уже последней сделкой в истории торгов может появиться еще одна сделка? Если изменилась сделка - другое. Но вклиниться внутри в уже имеющийся список - не замечал такого.
OrderExist и PositionExist - это специальные оптимизированные функции, которые позволяют избежать тупых переборов в цикле всех ордеров или позиций в поисках записей по символу, типу операции и меджику.
Результатом получаете массив с тикетами.
Программы могут серьезно сэкономить, используя эти функции. Особенно, когда массово, постоянно и многократно обращаются к открытым позициям и ордерам в переборных циклах.
В будущем мы реализуем более эффективные функции доступа к массивным данным торговых операций.
Язык тоже кардинально усилится и упростится с более мощным функционалом.
Хотите сказать, что перед уже последней сделкой в истории торгов может появиться еще одна сделка? Если изменилась сделка - другое. Но вклиниться внутри в уже имеющийся список - не замечал такого.
Теоретически, да.
Не забывайте про процессы синхронизации. Огромное количество процессов в платформе асинхронные.
Например, шлюз интеграции с биржей или провайдером ликвидности может прислать репорты по сделкам с задержками в секунды или даже минуты. Зачастую апи вообще не предоставляют доступа к истории для сверки, а дают медленные и не рилтаймовые генераторы отчетов.
На открытии рынка, или из-за неожиданного реконнекта шлюза репорты можно получить с задержкой. Они реплицируются в историю на сервере и тут же асинхронно отправляются в терминалы. Из-за сортировки по дате они вставляются в нужные места, а в это время вы можете открыть новые сделки.
Большинство интеграционных API такие безграмотные и нефункциональные, что почти начисто лишают возможности делать гарантированные шлюзы. Хотя есть мнение, что это продукт осознанного саботажа их разработчиков.
OrderExist и PositionExist - это специальные оптимизированные функции, которые позволяют избежать тупых переборов в цикле всех ордеров или позиций в поисках записей по символу, типу операции и меджику.
Результатом получаете массив с тикетами.
Программы могут серьезно сэкономить, используя эти функции. Особенно, когда массово, постоянно и многократно обращаются к открытым позициям и ордерам в переборных циклах.
В будущем мы реализуем более эффективные функции доступа к массивным данным торговых операций.
Язык тоже кардинально усилится и упростится с более мощным функционалом.
Ренат, большая просьба иметь доступ к котировкам за пределами TERMINAL_MAXBARS при использовании Copy.. функций. Хотя бы только минутный таймфрейм. Можно и отдельную функцию для этого сделать.
Просто чтобы иметь доступ к этим данным нужно постоянно ставить TERMINAL_MAXBARS в unlimited(да еще с перегрузкой терминала), что очень неудобно, т.к. не нужен unlimited на всех символах.
Ведь, насколько я понимаю, если копировать все немногочисленные бары MN1 периода, то все равно происходит закачка всех M1 баров, но доступа к ним нет.
Можно конечно все тики загружать, т.к. на них не распространяется это ограничение, но это более затратно по времени и тики, к сожалению, не всегда совпадают со всей минутной историей.
Ренат, большая просьба иметь доступ к котировкам за пределами TERMINAL_MAXBARS при использовании Copy.. функций. Хотя бы только минутный таймфрейм. Можно и отдельную функцию для этого сделать.
Просто чтобы иметь доступ к этим данным нужно постоянно ставить TERMINAL_MAXBARS в unlimited(да еще с перегрузкой терминала), что очень неудобно, т.к. не нужен unlimited на всех символах.
Ведь, насколько я понимаю, если копировать все немногочисленные бары MN1 периода, то все равно происходит закачка всех M1 баров, но доступа к ним нет.
Можно конечно все тики загружать, т.к. на них не распространяется это ограничение, но это более затратно по времени и тики, к сожалению, не всегда совпадают со всей минутной историей.
Нет, история вне этих лимитов не поднимается и не проверяется на синхронизированность. Тем более, негде их хранить(дополнительных невидимых кешей строить не будем), не будем лазать по диску в неэкономных режимах и не будем строить костылей.
Вообще это вредная идея, так как разработчики сразу же начнут писать абсолютно неэффективные алгоритмы, советовать трейдерам "поставьте 5000, а лучше 1000 баров" и обвинять нас в тормозах и неэффективностях.
Мы специально дали возможность контролировать объем ресурсов под чарты. Сейчас 64 бита и память дешевая - используйте подходящие настройки в рамках правил и архитектуры.
Менять это поведение не будем.
Нет, история вне этих лимитов не поднимается и не проверяется на синхронизированность. Тем более, негде их хранить(дополнительных невидимых кешей строить не будем) и не будем лазать по диску в неэкономных режимах.
И вообще это вредная идея, так как разработчики сразу же начнут писать абсолютно неэффективные алгоритмы, советовать трейдерам "поставьте 5000, а лучше 1000 баров" и обвинять нас в тормозах и неэффективностях.
Мы специально дали возможность контролировать объем ресурсов под чарты. Сейчас 64 бита и память дешевая - используйте подходящие настройки в рамках правил и архитектуры.
Менять это поведение не будем.
Ок. Понял. Спасибо. Вычеркиваю.
Хотя, конечно, хочется поспорить о неэкономности. Придется оставлять unlimited и в результате все открытые (например в данный момент у меня 14 чартов) будут хранить всю unlimited историю, хотя мне достаточно для большинства только 5000. Что наоборот будет более неэкономным.
Так же мне не нужно, чтобы эти данные хранились. О хранении я позабочусь. Я инициировал загрузку всех минутных баров, получил их в массив, и он мне больше не нужен и все кэши можно удалять, если их размер превышает TERMINAL_MAXBARS. Поэтому может быть для этого и нужна отдельная функция, которая не хранит кэшей.
Хотя, конечно, согласен, что шаловливые ручки могут такими периодическими загрузками подвесить систему.
У вас только два состояния 5000 и анлим?
Вы сами кузнец своего счастья.