Ошибки, баги, вопросы - страница 2754
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Смысл в возможности передать по ссылке.
Также как и со строками у Разработчиков есть возможность (если уже не сделали) итак все передавать по ссылке без фактического копирования переменной
И это будет решение не для одной конкретной структуры MqlTick, а на все случаи жизни
Что лишний раз подтверждает, что никакого смысла в использовании напрямую _Digits, _Point, _Period, _LastError и т.д. нет (и даже _Symbol можно заменить на NULL). Фактически они должны быть объявлены как const volatile
А Вы наоборот - предлагаете дополнить этот ряд
Вы правы, но только они почтиvolatile, кроме флага IsStopped - он volatile на 100%, т.е. любое чтение IsStopped, это 100% чтение памяти.
Для остальных, почтиvolatile - значит, что компилятор МОЖЕТ закешировать значение переменной в регистре при первом обращении и при следующем обращении к такой переменной использовать закешированное значение, но только в пределах одной функции или ветки вызовов, если они заинлайнились в одну функцию.
Это можно (и нужно), так как смена предопределённых переменных (кроме IsStopped) не может произойти внутри MQL точки входа (OnXXX функции)
По поводу МОДИФИКАТОРА ПЕРЕМЕННОЙconst, скажем так, что используeтся const программистами для программистов.
Как мы знаем, через приведение можно сменить константность епеременной, поэтому компилятору нельзя доверять модификатору const.
Если компилятор видит, что переменная не меняла значения и инициализируется константой, то он и без модификатора const превратит такую переменную в непосредственное значение (ImmediateValue)
По поводу _LastTick, мы обсуждаем, но...
Это структура, а не простой-атомарный тип и изменяться она может внезапно, в любой точке MQL программы, в том числе и во время получения значения.
Получается, что для адресации к этой структуре нужно вводить синхронизатор.
Мы постоянно работаем над производительностью, в частности из-за этого высокая частота выхода билдов.
В планах много работ по ускорению работы MQL-кода
По поводу _LastTick, мы обсуждаем, но...
Это структура, а не простой-атомарный тип и изменяться она может внезапно, в любой точке MQL программы, в том числе и во время получения значения.
Получается, что для адресации к этой структуре нужно вводить синхронизатор.
но в тестере _LastTick не может измениться в любой точке MQL программы ?
если да, то дайте такое решение только для тестера, где скорость расчетов наиболее важна
но в тестере _LastTick не может измениться в любой точке MQL программы ?
если да, то дайте такое решение только для тестера, где скорость расчетов наиболее важна
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными?
Мешает низкая квалификация создателей советников, которыми грузят Маркет и Облако.
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными? Это практически ничего не стоит. Зачем по 100 раз запрашивать его (как в приведённых ранее тестах), искусственно создавая тормоза на ровном месте. Т.е. проблему кривого кода советника предлагается решать усложнением внутренней работы МТ. Или у вас есть какие-то нормальные замеры?
события которые должен обработать "OnTick" поступают извне в некоторую очередь с приоритетами. В прочих обработчиках не лишне убедится, что подобных новых событий не прилетало, иначе данные прежнего тика невалидны/устарели
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными? Это практически ничего не стоит. Зачем по 100 раз запрашивать его (как в приведённых ранее тестах), искусственно создавая тормоза на ровном месте.
я именно так и делаю в тестере
Т.е. проблему кривого кода советника предлагается решать усложнением внутренней работы МТ. Или у вас есть какие-то нормальные замеры?
ну как бы кривость кода определяется устоявшимися приемами написания кода, посмотрите КБ и использование СБ в этих примерах
я не использую СБ, я замерял профилировщиком и искал решения несколько месяцев, был топик про тесты скорости, частично бросал альтернативные решения
нормальность замера? это скользкая тема, которой придется заниматься серьезно, меня устраивает мой ЕА для оптимизации, был проход на 18 месяцев 6 сек, сейчас 2,5 сек , имхо я проделал хорошую работу над собой )))
а не как сейчас 0, т.е. фактически REASON_PROGRAM
При перезапуске терминала постоянно и безостановочно пишет в журнал записи
Время исторического бара в записи постоянно увеличивается. График GBPUSD Daily открыт и дёргается - нулевой, первый и второй бары удаляются/создаются. И так по кругу.
Вот жду. То ли забьёт весь SSD этими логами, то ли остановится наконец...
Вчерашний лог в прицепе.