Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
я так понял - от оборудования всё зависит
Ничего подобного!
я так понял - от оборудования всё зависит
А я так думаю - нет )))
И даже не от загруженности компа...
Ничего подобного!
да! у Вас аппарат и у предыдущего - результат разные - значит я не прав,не от мощности значит
Что такое ОнМайн? Как в очереди в онмайне может оказаться больше одного события, если каждое событие вызывает онмайн для обработки очереди?
OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию "Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди". Это другой подход к самим вычислениям
OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию "Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди". Это другой подход к самим вычислениям
Так, на всякий случай, ОнМэйн...
:) ;)В боевых советниках везде в подозрительных местах облачил функции в _B(FuncName(...), AlertTime). Вот короткая выдержка лога из самых свежих записей.
Столбец времени показывает, как часто случаются фризы.Вы подменяете понятия.
Вот ваше исходное заявление:
К огромному сожалению, такой вызов HistorySelect длится 5-30 миллисекунд (самостоятельно замерял в Release-EX5). Когда в советнике в OnTick делается несколько подобных актуализаций (по-хорошему, нужно делать после любой паузы. Например, после каждого OrderSend.), то все становится безумно дорогим/долгим. HistorySelect может суммарно в одном OnTick съедать несколько секунд.
Даже в вашем терминале среднее время в 0.2 мс на один вызов ощутимо меньше указанных в исходном утверждении величин.
Теперь вы утверждаете, что иногда время выполнения функции может быть ощутимо дольше среднего. Это другой вопрос.
Любой запрос HistorySelect() является полноценным обращением к базам терминала под синхронизаторами. Это неизбежно. Да, с учетом наличия синхронизации доступа, гарантировать сверхмалое время выполнения этой функции нельзя.
Предложеное решение через добавление функций HistoryDealsSelect() и HistoryOrdersSelect() в этом смысле абсолютно ничего не меняет.
Скрипт для проверки максимального и среднего времени:
Скрипт для проверки максимального и среднего времени:
Не буду комментировать Ваше мнение до процитированного. Вот результат запуска Вашего скрипта.
Точнее, я не смог дождаться его конца, поэтому заменил количество итераций со 100K на 1К.
Разве это тянет даже на оценку удовлетворительно?
Вы посмотрите всю абсурдность ситуации. Чтобы тупо узнать количество сделок, нужно вызывать HistorySelect! Это, мягко говоря, не рационально.
ЗЫ На каждом тике в лучшем случае трачу суммарно десятки миллисекунд только из-за HistorySelect.
В самом простейшем виде:
Просто нужно изменить подход к самим вычислениям (делайте промежуточный return так часто как это требует задача). Но если это сложно, то считайте на 1ом этапе, что OnMain для Вас как бы и нет (Вы же основной код переносите не в OnMain, а в OnTrade2XX) соответственно в OnMain не нужно ничего узнавать
Спасибо, именно так изначально и понял, поэтому и высказал, что не до конца понимаете. Примером покажу на простом сценарии.
Вы делаете OrderSend. Если СРАЗУ после окончания OrderSend определенная позиция не закрылась по тейку, то делаете еще один OrderSend. Это вся логика, которую надо запрограммировать. Async не используем.
Теперь ситуация, которая произошла для нашего робота. Вы отправили OrderSend, и пока он выполнялся произошло срабатывание лимитника и после этого срабатывание тейка нашей позиции, что упоминал выше.
Какая реализация робота схематично? Не знаю, как реализовать это без тормозной HistorySelect или костыля OnTradeTransaction-шпиона, который дает доступ в любом месте кода ко всей истории транзакций. Если бы был реализован механизм доступа к очереди событий, то пример выше решался бы элементарно.
Всех сильных в MT5, включая разработчиков, просьба показать, как эту (жирным выше две строки выделены) незамысловатую (про сложные даже упоминать боюсь) торговую логику реализовать.
OnMain - это функция. Это не фактический код, а частный случай - ответ на претензию " Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди". Это другой подход к самим вычислениям
Ну так ведь так и есть. И парни про это и говорили. Для реализации нужно менять структуру выполнения MQL-программ либо а) хотя бы на двухпоточную, либо б) добавлять механизм доступа к очереди и управления её обработкой .
При текущей структуре вами предложенную схему невозможно реализовать.