Можно ли обойтись без цикла подсчета / пересчета ордеров имея оригинальные тикеты ордеров? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Проверка количества "сейчас и на прошлой проверке" - это неоправданное усложнение кода? А мотать циклы на каждом тике вместо проверки необходимости их крутить - это оправдано для тестера и оптимизации?
да усложнение
есть некая "идея-фикс", что если вот взять и сохранить все окружение терминала в свой код, то получу выигрыш в производительности - получишь, но до определенного уровня усложнения кода
любая программа это алгоритм + данные, если можешь не увеличивать код алгоритма и увеличивать обьем данных хранящихся локально - это выигрыш в производительности,
но если код алгоритма увеличивается значительно, то будет наоборот потеря производительности - процессор мало того, что будет больше инструкций в потоке выполнения программы молотить, дык ему еще придется сам исполняемый код постоянно подгружать и выгружать когда нужно будет освободить ресурсы для другого процесса , т.е. сам код тоже имеет физический размер который нужно будет прокачивать по шине, кэшу, регистрам и АЛУ процессора
вот если бы был монопольный режим владения процессором, и кэш процессора был бы бесконечный... но это из области "закрой глаз - размечтался одноглазый!" )))
Или вам нужно просто что-нибудь сказать против именно моих сообщений - ну тогда не буду отвлекать от развлечений. Продолжайте.
Вы опять за старое - когда нет аргументов, то сразу переходить на личности? вопрос мне интересен, читал, где не согласен вступил в обсуждение, не припомню попойки на бурдершафт, что бы выделять участников форума по личностным соображениям, сменишь аватарку, вообще будешь другой человек для меня - внимательность не мой конек - на полном серьезе
технический форум без единой строчки кода
))))
вот проверил, что писал - время написания, ну минут 5 с перекурами вышло
итого перебор по 10-ти ордерам по 1 млн раз (с учетом проверки символа и магика) занимает 0.11 секунды...ну как бы есть куда расти
Под пивасик затестил (а че? Питница - имею право))):
Функция NanoCount():
Результат:
Для чистоты эксперимента - второй раз:
Дальше сами)))
Нет, имея тикет, ордер нельзя разделять по пулам. Он будет всегда выбран, если имеется среди рабочих или в истории счета. Чтобы понять, какому пулу принадлежит ордер, нужно запросить время закрытия. У рабочих оно равно нулю. Соответственно у закрытых/удаленных - больше нуля.
Я правильно понял OrderCloseTime()!=0 для отложенных ордеров тоже работает? Этого нет в документации.
Не нужно на каждом тике циклов выбора и проверки. Достаточно сравнить прошлое количество с текущим (как рыночных, так и исторических) для принятия решения о необходимости лезть в список ордеров и позиций.
Это решение понятно. Вопрос в другом. Как имея тикет и структура ордера заполнена по этому тикету узнать состояние ордера? Вернее тогда что можно узнать, а что нельзя узнать. В документации не нашел.
И повторюсь)
Так правильно, с флагом по тикету или ошибка будет? В документации написано что зона выбора рыночные / исторические ордера указывается только для флага по номеру.
Закроется ордер через час или нет? В доках не нашел.
Я правильно понял OrderCloseTime()!=0 для отложенных ордеров тоже работает? Этого нет в документации.
Это решение понятно. Вопрос в другом. Как имея тикет и структура ордера заполнена по этому тикету узнать состояние ордера? Вернее тогда что можно узнать, а что нельзя узнать. В документации не нашел.
И повторюсь)
Так правильно, с флагом по тикету или ошибка будет? В документации написано что зона выбора рыночные / исторические ордера указывается только для флага по номеру.
Закроется ордер через час или нет? В доках не нашел.
В продолжение. Алгоритм на тике Событие, проверка типа ордера, принятие решения.
Редкая ситуация. Событие, проверка типа ордера в момент изменения этого типа, ордер стал рыночным. Какова вероятность ошибки проверки типа ордера в зависимости от того, где находиться проверка, в начале и в конце кода?
Artyom Trishkin:
Когда изменятся количества рыночных и исторический ордеров, на этом тике или на следующем?
Дальше сами)))
увы, уровень не тот у нас тут )))
насколько понимаю, тестили чистый OrderSelect() и получили около 1000 * 10^-6 сек т. 0.001 сек - в общем не суть, много что можно потестировать, а вот то , что разработчики МТ наиболее часто вызываемые юзерами фичи сделали максимально производительными
ЗЫ: в прошлом году был удивлен в ходе очередной баталии, что даже iCustom() в МТ4 заоптили так, что один физический вызов iCustom() , а в коде будет несколько вызовов чтоб получить несколько буферов на одном тике - топик не найду уже
Так правильно, с флагом по тикету или ошибка будет? В документации написано что зона выбора рыночные / исторические ордера указывается только для флага по номеру.
при выборе по тикету, значение MODE_TRADES / MODE_HISTORY не учитывается https://docs.mql4.com/ru/trading/orderselect
Примечание
Параметр pool игнорируется, если ордер выбирается по номеру тикета. Номер тикета является уникальным идентификатором ордера.
У тебя есть возможность создавать и работать с объектами, в том числе и с динамическими. В чем проблема? На каждый ордер - свой объект. Каждый тик проверяешь его состояние, когда не нужен уже - delete и все.
можно вообще структуру с operator== написать и тупо после заполнения структуры выбранного ордера через OrderSelect(), сравнивать с запомненной - код компактный будет
с обьектами, да - очень удобно, что можно динамически создавать через new и удалять когда не нужен, но скорость ниже, хотя если работать с десятком или двумя ордеров - вообще не принципиально
У тебя есть возможность создавать и работать с объектами, в том числе и с динамическими. В чем проблема? На каждый ордер - свой объект. Каждый тик проверяешь его состояние, когда не нужен уже - delete и все.
Про объекты не понял, и полагаю это затратно. Хочется найти наименее затратные решения. Вроде если ордер выбран, структура ордера заполнена, что можно узнать, а что нельзя одним запросом.
В продолжение. Алгоритм на тике Событие, проверка типа ордера, принятие решения.
Редкая ситуация. Событие, проверка типа ордера в момент изменения этого типа, ордер стал рыночным. Какова вероятность ошибки проверки типа ордера в зависимости от того, где находиться проверка, в начале и в конце кода?
Artyom Trishkin:
Когда изменятся количества рыночных и исторический ордеров, на этом тике или на следующем?
Ты работаешь с контекстом, который был при последнем вызове OrderSelect,
Про объекты не понял, и полагаю это затратно. Хочется найти наименее затратные решения. Вроде если ордер выбран, структура ордера заполнена, что можно узнать, а что нельзя одним запросом.
Кто Вам такие глупости внушил?
Кто Вам такие глупости внушил?
разница есть, но только на операторы new и delete https://www.mql5.com/ru/forum/222141/page20#comment_13519247
но тут вопрос тогда в логике программы - если на одном тике по пару сотен тысяч раз создавать обьекты и удалять при выходе из OnTick() - с обьектами беда будет
ЗЫ:
я ж пишу, уровень у нас не тот, нам бы логики написания производительных программ пару мешков в довесок, но ввиду неимения оной - грешим на производительность .... даже не знаю, и терминала не хватает и ПК слабоваты, в общем как пословица про плохого танцора которому ...
)))