Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Даже так бывает выигрывает верхний код но уже очень редко т.е. переход по ссылке - считай бесплатный
) ну это немного не так работает)
Вот так работает в С++
В mql думаю так же, но с доп обертками от MQ
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Вопросы от начинающих MQL5 MT5 MetaTrader 5
Roman, 2019.12.11 14:02
Конечно не надо продумывать, а зачем... компилятор сам всё сделает. ))
C# не С
А по __inline смотри видос.
Там как раз объясняется как работают функции в памяти, для тех кому нет ни какой разницы.
Вот так работает в С++
В mql думаю так же, но с доп обертками от MQ
ну а теперь перечитываем эту ветку и кучу утверждений и примеров тестов - что есть какая-то разница. И ведь нашли)))
ну а теперь перечитываем эту ветку и кучу утверждений и примеров тестов - что есть какая-то разница. И ведь нашли)))
Не )) перечитывать мне нет желания.
Для меня и так всё очевидно, что разница есть.
Не )) перечитывать мне нет желания.
Для меня и так всё очевидно, что разница есть.
))) очередное ИМХО
Верхний способ быстрее на почти 15% это очень существенно, ну раз все так очевидно объясните мне)
))) очередное ИМХО
Верхний способ быстрее на почти 20%, ну раз все так очевидно объясните мне)
Сравниваемые циклы не одинаковы по коду в теле.
В первом цикле в теле один код, во втором теле цикла другой код.
Естественно разные инструкции кода, естественно разное время выполнения.
Сделайте в теле цикла одинаковый код, и меняйте только условие цикла ArraySize и переменная size.
Мы же эту часть тестируем, а не тело.
Сравниваемые циклы не одинаковы по коду в теле.
В первом цикле в теле один код, во втором теле цикла другой код.
Естественно разные инструкции кода, естественно разное время выполнения.
Сделайте в теле цикла одинаковый код, и меняйте только условие цикла ArraySize и переменная size.
Мы же эту часть тестируем, а не тело.
Ваш тест более некорректен т.к. зависит от случая запуска, по запускайте еще. Здесь же в обоих случаев есть приращение и одно деление. Ну + сверху еще есть лишние пару десятков ~ миллиардов вызовов ArraySize
Кстати именно в тело и надо записывать то что тестируем. Т.к. именно тело повторяется. Мы же чтобы получить результат пытаемся его обернуть в цикл.... т.е. это изначально надо было ArraySize вызывать из тела
Ваш тест более некорректен т.к. зависит от случая запуска, по запускайте еще. Здесь же в обоих случаев есть приращение и одно деление. Ну + сверху еще есть лишние пару десятков ~ миллиардов вызовов ArraySize
Кстати именно в тело и надо записывать то что тестируем. Т.к. именно тело повторяется. Мы же чтобы получить результат пытаемся его обернуть в цикл.... т.е. это изначально надо было ArraySize вызывать из тела
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size
То есть на каждой итерации идёт обращение или к функции или к переменной.
Зачем в тело то помещать тестируемый объект?
Тут сама логика подсказывает, к чему будет обращение быстрее? К функции или к переменной.
Как там заинлайнит компилятор, меня не волнует. Я не полагаюсь на компилятор, а исхожу из здравого смысла, что быстрее обрабатывается с точки зрения обращения.
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size
То есть на каждой итерации идёт обращение или к функции или к переменной.
Зачем в тело то помещать тестируемый объект?
Потому что это нам повезло с этой функцией, функция может быть любая другая. И её ставят именно в тело. И то что я продублировал её пытаясь лишь усилить эффект причем обращаясь к различным массивам.
А вот неверно - добавлять более сложные задачи, погрешность расчета которых может затмить исследуемый эффект. Кстати еще возможно что сборка не постоянна у мкл вроде. т.е. при перекомпиляции может получить немного другие данные (хотя это не точно, но это вроде использую как защиту от взлома) Так что все можно по тестировать и на вашем коде вам же. Глядишь и изменяться результаты.
Мкл просто пытается подставлять код как указано на видео. Ну так то там немного не так все. Но в общих словах.
А те инструкции у функций которые не знают какое значения получат - так работает js и php и прочие подобные языки, даже мкл так работает но только в режиме отладки
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size
То есть на каждой итерации идёт обращение или к функции или к переменной.
Зачем в тело то помещать тестируемый объект?
Тут сама логика подсказывает, к чему будет обращение быстрее? К функции или к переменной.
Как там заинлайнит компилятор, меня не волнует. Я не полагаюсь на компилятор, а исхожу из здравого смысла, что быстрее обрабатывается с точки зрения обращения.
Это не всегда работает.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
вопрос к знатокам #define
Roman, 2020.11.02 19:44
Изменил свой пост.
Как то наоборот получается ArraySize теперь быстрее отрабатывает, чем переменная cnt.
Раньше наоборот было. Наверно инкремент cnt-- влияет, тело цикла разные и наверно надо что то другое придумать для нагрузки.