Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пожалуйста, приведите элементарную схему-код этой идеи. На первый взгляд звучит, как полное непонимание.
Во время выполнения OnMain-функции нет возможности узнать состояние текущей реальной очереди. Единственный обходный вариант это сделать - программа шпион, как приводил по ссылке.
В самом простейшем виде:
Просто нужно изменить подход к самим вычислениям (делайте промежуточный return так часто как это требует задача). Но если это сложно, то считайте на 1ом этапе, что OnMain для Вас как бы и нет (Вы же основной код переносите не в OnMain, а в On2XX) соответственно в OnMain не нужно ничего узнавать
Костыли не в том направлении делаете:
Оставьте в OnXXX функциях только копирование событий (параметров) в очереди и вызова основной OnMain функции. Перенесите весь их код в дублирующие On2XX функции. И вызывайте из OnMain эти дублирующие On2XX функции в той последовательности, в которой Вам нужно, в свою очередь передавая им в качестве параметров данные из очередей
Далее проведите замеры - покажите выигрыш в скорости и тогда уже можно будет предлагать дополнить MQL соответствующим функционалом. Но зачем дополнять, если Вы и так уже все сделали сами здесь и сейчас?!
Вы не о том пишите.
Проблема в том что функционал заполнения полей у входных переменных функции "OntaredeTransaction" не соответствует описанию, данному в Справке, в худшую сторону:
т.е. множество полей не заполняются в вызовах, и даже в конечном вызове TRADE_TRANSACTION_HISTORY_ADD.
Соответственно все трейдеры мучаются тут чтобы в момент прихода как-то эти недостающие параметры определить.
Тут была масса обсуждений, просто сделайте поиск по форуму - кривой функционал "OntaredeTransaction" порождает доп. затраты при обработке. как по времени, так и "грузит" алготрейдеров лишними трудозатратами времени на разрабоку адекватно работающего кода (т.е. массовая потери времени и колоссальная неэффективность на уровне всего сообщества).
Теущие отписки разрабов типа "Если у вас по символу Market execution, то будет нулевое значение цены; Так и должно быть." (Ссылка) - это НЕНОРМАЛЬНО, еще раз -
отсутствие исчерпывающих значений в последнем вызовах функции приводит к массе доп. трудозатрат.
HistorySelect.
Это безумно дорогая функция. И, к сожалению, никакие кеширования не позволяют сделать приемлемой скорость ее работы сейчас.
Например, в боевых советниках важно работать с актуальными данными. В частности, чтобы тики из Обзора рынка и CopyTicks по возможности не были устаревшими.
Для этого имеются не очень хорошие, но вынужденные механизмы проверки актуальности текущих ценовых данных. Одной из частей такого механизма является детектирование ситуаций, когда сделка по символу прошла позже последнего тика. Такое случается не редко, поэтому важно знать, является ли текущий тик еще актуальным или нет.
Для подобного детектирования нужно иметь возможность обращения к истории последних сделок. Делается это через HistorySelect следующим схематичным образом.
К огромному сожалению, такой вызов HistorySelect длится 5-30 миллисекунд (самостоятельно замерял в Release-EX5). Когда в советнике в OnTick делается несколько подобных актуализаций (по-хорошему, нужно делать после любой паузы. Например, после каждого OrderSend.), то все становится безумно дорогим/долгим. HistorySelect может суммарно в одном OnTick съедать несколько секунд.
Уважаемые разработчики, почему так дорого? Эта функция может выполняться мгновенно при должной реализации.
У вас есть доказательства про " такой вызов HistorySelect длится 5-30 миллисекунд"?
Если я правильно понял вышу мысль, то тестовый код должен выглядеть так:
Вот так отрабатывают 100000 запросов:
У вас есть доказательства про " такой вызов HistorySelect длится 5-30 миллисекунд"?
Если я правильно понял вышу мысль, то тестовый код должен выглядеть так:
Вот так отрабатывают 100000 запросов:
У вас есть доказательства про " такой вызов HistorySelect длится 5-30 миллисекунд"?
Если я правильно понял вышу мысль, то тестовый код должен выглядеть так:
Вот так отрабатывают 100000 запросов:
Запуск Вашего скрипта.
Запуск другого скрипта.
Обычный боевой счет. Не HFT.
ЗЫ Кстати, Ваш скрипт показал, что HistorySelect каждый раз заново все вычисляет. А ведь входные параметры не менялись, таблица истории не обновлялась, другие HistorySelect-функции не вызывались.
Запуск Вашего скрипта.
Значит нужны подробности.
Мой тест запускался на не самом быстром "Intel Xeon E5-2630 v4 @ 2.20GHz" с массой других процессов в фоне.
На тестовом счете в истории было 31315 ордеров более-менее равномерно начиная с 2009 года, втч 8 ордеров за сегодняшний день.
Возможно у вас одновременно работал какой-то скрипт или эксперт радикально нагружающий базы терминала. Попробуйте на "чистом" терминале.
Более информативный тест:
Три запуска:
Значит нужны подробности.
Мой тест запускался на не самом быстром "Intel Xeon E5-2630 v4 @ 2.20GHz" с массой других процессов в фоне.
На тестовом счете в истории было 31315 ордеров более-менее равномерно начиная с 2009 года, втч 8 ордеров за сегодняшний день.
Возможно у вас одновременно работал какой-то скрипт или эксперт радикально нагружающий базы терминала. Попробуйте на "чистом" терминале.
Пустой Терминал на этом же счете и машине.
На других счетах и Терминалах подобная же картина. Конфигурация.
Просьба читателей привести свои результаты этого скрипта.
Более информативный тест:
Три запуска:
Пустой Терминал 2460.
ЗЫ Запуск на пустом счете.
Похоже, на скорость сильно влияет количество сделок, не ордеров.
Пустой Терминал на этом же счете и машине.
На других счетах и Терминалах подобная же картина. Конфигурация.
Просьба читателей привести свои результаты этого скрипта.
Это ничего не доказывает, но то, что с каждым новым запуском (на другом символе), время увеличивается - настораживает...
Нужно запустить на счете с большой историей торговли.