MT5 и скорость в боевом исполнении - страница 17

 

Учтите, что HistorySelect делает физический снепшот выбранной истории в локальный кеш эксперта, чтобы можно было без боязни их перебирать. Без этого можно получить очень неприятные эффекты, так как история счета обновляется/синхронизируется асинхронно. Это не говоря уже о том, что пользователь сам вручную может из интерфейса поменять глубину истории.

Поэтому и такие расходы на копирование. Тем более, если специально заниматься одновременным принудительным копированием этой истории в кеш из множества потоков.

Мы уже многое оптимизировали в операциях выборок и сейчас думаем над оптимальным обновлением кеша, когда в реальности 99% выборок будут полностью бесполезными и пропускаться по факту.

То есть, если не будете специально рандомизировать пределы выборок, то кеш будет показывать попадания, близкие к 100%.

Скорее всего на следующей неделе уже будет эффективное решение.

 
Renat Fatkhullin:

Учтите, что HistorySelect делает физический снепшот выбранной истории в локальный кеш эксперта, чтобы можно было без боязни их перебирать. Без этого можно получить очень неприятные эффекты, так как история счета обновляется/синхронизируется асинхронно. Это не говоря уже о том, что пользователь сам вручную может из интерфейса поменять глубину истории.

Есть таблица ордеров и таблица сделок. Зачем делать физические снепы, когда достаточно знать четыре индекса на момент вызова HistorySelect?

Поэтому и такие расходы на копирование. Тем более, если специально заниматься одновременным принудительным копированием этой истории в кеш из множества потоков.

Мы уже многое оптимизировали в операциях выборок и сейчас думаем над оптимальным обновлением кеша, когда в реальности 99% выборок будут полностью бесполезными и пропускаться по факту.

То есть, если не будете специально рандомизировать пределы выборок, то кеш будет показывать попадания, близкие к 100%.

Скорее всего на следующей неделе уже будет эффективное решение.

HistoryDealSelect и HistoryOrderSelect сейчас уничтожают соответствующие выборки. Почему нет, как в MT4, доступа к обеим таблицам по индексам? Вводите же новый функционал.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Ошибки, баги, вопросы

fxsaber, 2020.08.20 11:28

Новые штатные функции.
int OrderExist( const string symbol, ENUM_ORDER_TYPE type, ulong magic, ulong &tickets[] );

int PositionExist( const string symbol, ENUM_POSITION_TYPE type, ulong magic, ulong &tickets[] );

Индексы напрашиваются. Совсем непонятно, почему через одно место нужно узнавать количество сделок на счете.

 

И эти таблицы могут в любой момент измениться. Как и отдельные записи в них.

Никто не может гарантировать их неизменность из-за асинхронных операций, процессов синхронизации и режимов глубины, выставляемых пользователями вручную.

Как я писал выше, мы применим методы интеллектуального кеширования, что снизит до нуля расходых на Select функции. Если, конечно, не будете специально рандомизировать пределы выборок. Последнюю дату можно менять и она не будет инвалидировать кеш, если она всегда будет в будущем/послднем времени. Последние транзакции будут экономно добавляться в кеш.


В МТ4 работает так же, просто создание кеша скрыто. На каждом OnTick/OnStart МТ4 терминал автоматически и экономно создает снепшот рыночного окружения для каждого эксперта.

Поэтому вы не можете оценить истинных задержек на подготовке данных из MQL4 кода. К счастью, в МТ4 данных мало и все просто.


В МТ5 мы отказались от затрат на автоматическое создание рыночного окружения, чтобы снизить задержки и не делать лишней работы. Вместо этого мы дали полный контроль над расходами разработчикам роботов, которые могут запрашивать ровно то, что им нужно.

Обратите внимание, что обьем рыночного окружения в МТ5 огромен по сравнению с МТ4 - его попросту нельзя реплицировать.

Своими тестами вы воспользовались одной из таких затратных выборок.

Мы это исправим - это в наших интересах.

 
Renat Fatkhullin:

И эти таблицы могут в любой момент измениться. Как и отдельные записи в них.

Никто не может гарантировать их неизменность из-за асинхронных операций, процессов синхронизации и режимов глубины, выставляемых пользователями вручную.

Хотите сказать, что перед уже последней сделкой в истории торгов может появиться еще одна сделка? Если изменилась сделка - другое. Но вклиниться внутри в уже имеющийся список - не замечал такого.

 

OrderExist и PositionExist - это специальные оптимизированные функции, которые позволяют избежать тупых переборов в цикле всех ордеров или позиций в поисках записей по символу, типу операции и меджику.

Результатом получаете массив с тикетами.


Программы могут серьезно сэкономить, используя эти функции. Особенно, когда массово, постоянно и многократно обращаются к открытым позициям и ордерам в переборных циклах.

В будущем мы реализуем более эффективные функции доступа к массивным данным торговых операций.

Язык тоже кардинально усилится и упростится с более мощным функционалом.

 
fxsaber:

Хотите сказать, что перед уже последней сделкой в истории торгов может появиться еще одна сделка? Если изменилась сделка - другое. Но вклиниться внутри в уже имеющийся список - не замечал такого.

Теоретически, да.

Не забывайте про процессы синхронизации. Огромное количество процессов в платформе асинхронные.

Например, шлюз интеграции с биржей или провайдером ликвидности может прислать репорты по сделкам с задержками в секунды или даже минуты. Зачастую апи вообще не предоставляют доступа к истории для сверки, а дают медленные и не рилтаймовые генераторы отчетов.

На открытии рынка, или из-за неожиданного реконнекта шлюза репорты можно получить с задержкой. Они реплицируются в историю на сервере и тут же асинхронно отправляются в терминалы. Из-за сортировки по дате они вставляются в нужные места, а в это время вы можете открыть новые сделки.

Большинство интеграционных API такие безграмотные и нефункциональные, что почти начисто лишают возможности делать гарантированные шлюзы. Хотя есть мнение, что это продукт осознанного саботажа их разработчиков.

 
Renat Fatkhullin:

OrderExist и PositionExist - это специальные оптимизированные функции, которые позволяют избежать тупых переборов в цикле всех ордеров или позиций в поисках записей по символу, типу операции и меджику.

Результатом получаете массив с тикетами.


Программы могут серьезно сэкономить, используя эти функции. Особенно, когда массово, постоянно и многократно обращаются к открытым позициям и ордерам в переборных циклах.

В будущем мы реализуем более эффективные функции доступа к массивным данным торговых операций.

Язык тоже кардинально усилится и упростится с более мощным функционалом.

Ренат, большая просьба иметь доступ к котировкам за пределами  TERMINAL_MAXBARS при использовании Copy.. функций. Хотя бы только минутный таймфрейм. Можно и отдельную функцию для этого сделать.
Просто чтобы иметь доступ к этим данным нужно постоянно ставить  TERMINAL_MAXBARS в unlimited(да еще с перегрузкой терминала), что очень неудобно, т.к. не нужен unlimited на всех символах.
Ведь, насколько я понимаю, если копировать все немногочисленные бары MN1 периода, то все равно происходит закачка всех M1 баров, но доступа к ним нет. 
Можно конечно все тики загружать, т.к. на них не распространяется это ограничение, но это более затратно по времени и тики, к сожалению, не всегда совпадают со всей минутной историей. 

 
Nikolai Semko:

Ренат, большая просьба иметь доступ к котировкам за пределами  TERMINAL_MAXBARS при использовании Copy.. функций. Хотя бы только минутный таймфрейм. Можно и отдельную функцию для этого сделать.
Просто чтобы иметь доступ к этим данным нужно постоянно ставить  TERMINAL_MAXBARS в unlimited(да еще с перегрузкой терминала), что очень неудобно, т.к. не нужен unlimited на всех символах.
Ведь, насколько я понимаю, если копировать все немногочисленные бары MN1 периода, то все равно происходит закачка всех M1 баров, но доступа к ним нет. 
Можно конечно все тики загружать, т.к. на них не распространяется это ограничение, но это более затратно по времени и тики, к сожалению, не всегда совпадают со всей минутной историей. 

Нет, история вне этих лимитов не поднимается и не проверяется на синхронизированность. Тем более, негде их хранить(дополнительных невидимых кешей строить не будем), не будем лазать по диску в неэкономных режимах и не будем строить костылей.

Вообще это вредная идея, так как разработчики сразу же начнут писать абсолютно неэффективные алгоритмы, советовать трейдерам "поставьте 5000, а лучше 1000 баров" и обвинять нас в тормозах и неэффективностях.

Мы специально дали возможность контролировать объем ресурсов под чарты. Сейчас 64 бита и память дешевая - используйте подходящие настройки в рамках правил и архитектуры.

Менять это поведение не будем.

 
Renat Fatkhullin:

Нет, история вне этих лимитов не поднимается и не проверяется на синхронизированность. Тем более, негде их хранить(дополнительных невидимых кешей строить не будем) и не будем лазать по диску в неэкономных режимах.

И вообще это вредная идея, так как разработчики сразу же начнут писать абсолютно неэффективные алгоритмы, советовать трейдерам "поставьте 5000, а лучше 1000 баров" и обвинять нас в тормозах и неэффективностях.

Мы специально дали возможность контролировать объем ресурсов под чарты. Сейчас 64 бита и память дешевая - используйте подходящие настройки в рамках правил и архитектуры.

Менять это поведение не будем.

Ок. Понял. Спасибо. Вычеркиваю. 
Хотя, конечно, хочется поспорить о неэкономности. Придется оставлять unlimited и в результате все открытые (например в данный момент у меня 14 чартов) будут хранить всю unlimited историю, хотя мне достаточно для большинства только 5000. Что наоборот будет более неэкономным.
Так же мне не нужно, чтобы эти данные хранились. О хранении я позабочусь. Я инициировал загрузку всех минутных баров, получил их в массив, и он мне больше не нужен и все кэши можно удалять, если их размер превышает  TERMINAL_MAXBARS. Поэтому может быть для этого и нужна отдельная функция, которая не хранит кэшей.

Хотя, конечно, согласен, что шаловливые ручки могут такими периодическими загрузками подвесить систему.

 

У вас только два состояния 5000 и анлим?

Вы сами кузнец своего счастья.