Верхний способ быстрее на почти 20%, ну раз все так очевидно объясните мне)
Сравниваемые циклы не одинаковы по коду в теле. В первом цикле в теле один код, во втором теле цикла другой код. Естественно разные инструкции кода, естественно разное время выполнения. Сделайте в теле цикла одинаковый код, и меняйте только условие цикла ArraySize и переменная size. Мы же эту часть тестируем, а не тело.
Сравниваемые циклы не одинаковы по коду в теле. В первом цикле в теле один код, во втором теле цикла другой код. Естественно разные инструкции кода, естественно разное время выполнения. Сделайте в теле цикла одинаковый код, и меняйте только условие цикла ArraySize и переменная size. Мы же эту часть тестируем, а не тело.
Ваш тест более некорректен т.к. зависит от случая запуска, по запускайте еще. Здесь же в обоих случаев есть приращение и одно деление. Ну + сверху еще есть лишние пару десятков ~ миллиардов вызовов ArraySize
Кстати именно в тело и надо записывать то что тестируем. Т.к. именно тело повторяется. Мы же чтобы получить результат пытаемся его обернуть в цикл.... т.е. это изначально надо было ArraySize вызывать из тела
Ваш тест более некорректен т.к. зависит от случая запуска, по запускайте еще. Здесь же в обоих случаев есть приращение и одно деление. Ну + сверху еще есть лишние пару десятков ~ миллиардов вызовов ArraySize
Кстати именно в тело и надо записывать то что тестируем. Т.к. именно тело повторяется. Мы же чтобы получить результат пытаемся его обернуть в цикл.... т.е. это изначально надо было ArraySize вызывать из тела
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size То есть на каждой итерации идёт обращение или к функции или к переменной. Зачем в тело то помещать тестируемый объект?
Тут сама логика подсказывает, к чему будет обращение быстрее? К функции или к переменной. Как там заинлайнит компилятор, меня не волнует. Я не полагаюсь на компилятор, а исхожу из здравого смысла, что быстрее обрабатывается с точки зрения обращения.
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size То есть на каждой итерации идёт обращение или к функции или к переменной. Зачем в тело то помещать тестируемый объект?
Потому что это нам повезло с этой функцией, функция может быть любая другая. И её ставят именно в тело. И то что я продублировал её пытаясь лишь усилить эффект причем обращаясь к различным массивам.
А вот неверно - добавлять более сложные задачи, погрешность расчета которых может затмить исследуемый эффект. Кстати еще возможно что сборка не постоянна у мкл вроде. т.е. при перекомпиляции может получить немного другие данные (хотя это не точно, но это вроде использую как защиту от взлома) Так что все можно по тестировать и на вашем коде вам же. Глядишь и изменяться результаты.
Мкл просто пытается подставлять код как указано на видео. Ну так то там немного не так все. Но в общих словах.
А те инструкции у функций которые не знают какое значения получат - так работает js и php и прочие подобные языки, даже мкл так работает но только в режиме отладки
Информация о запущенной MQL5-программе - Состояние окружения - Константы, перечисления и структуры - Справочник MQL5 - Справочник по языку алгоритмического/автоматического трейдинга для MetaTrader 5
На каждой итерации, в условии цикла и так происходит проверка условия i<ArraySize() или i<size То есть на каждой итерации идёт обращение или к функции или к переменной. Зачем в тело то помещать тестируемый объект?
Тут сама логика подсказывает, к чему будет обращение быстрее? К функции или к переменной. Как там заинлайнит компилятор, меня не волнует. Я не полагаюсь на компилятор, а исхожу из здравого смысла, что быстрее обрабатывается с точки зрения обращения.
Изменил свой пост. Как то наоборот получается ArraySize теперь быстрее отрабатывает, чем переменная cnt. Раньше наоборот было. Наверно инкремент cnt-- влияет, тело цикла разные и наверно надо что то другое придумать для нагрузки.
voidOnStart()
{
int arr[];
int sz = ArrayResize(arr, 100000000);
ulong t = GetMicrosecondCount();
for(int i=0; i < ArraySize(arr); i++)
{
ArrayResize(arr, sz--); //какая то нагрузка
}
t = GetMicrosecondCount() - t;
PrintFormat("Total time: %.3f ms", t / 1000.0);
}
2020.11.0221:33:22.863 TestScript (USDJPY,M1) Total time: 451.200 ms
voidOnStart()
{
int arr[];
int sz = ArrayResize(arr, 100000000);
int cnt = ArraySize(arr);
ulong t = GetMicrosecondCount();
for(int i=0; i < cnt; i++)
{
ArrayResize(arr, sz--);
cnt--;
}
t = GetMicrosecondCount() - t;
PrintFormat("Total time: %.3f ms", t / 1000.0);
}
2020.11.0221:56:26.591 TestScript (USDJPY,M1) Total time: 531.872 ms
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Даже так бывает выигрывает верхний код но уже очень редко т.е. переход по ссылке - считай бесплатный
) ну это немного не так работает)
Вот так работает в С++
В 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-- влияет, тело цикла разные и наверно надо что то другое придумать для нагрузки.