Возможно ли избегнуть много "или" (||) в условиях, вызывающих одно и то же действие? - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
borilunad, любые вызовы функций добавляют лишние тормоза. Поэтому если требуется максимальная скорость, то нужно избавляться от всяких Request(), выполняющих односложные операции. Это же односится и к циклам. Проверка уловий в цикле всегда значительно медленней, чем просто серия вложенных if()
Значит, даже взаимоисключающие условия лучше с if(A || B || C || D) Action;
Но вызовов функций не могу избегнуть, т.к. необходимо в этот момент проверять много данных, которые включены в эти условия.
Буду продолжать эксперименты, может что выкопаю. Но на спрэд управы нет! :)
Впрочем, строчку else result=false лучше совместить с первой строчкой, на скорости это практически не отразится. Да и вообще, если A, B, C и D содержат простые условия (с минимумом арифметических действий, без вызова всяких математических функций и прочих прибамбасов), то особого выигрыша в производительности ты не получишь от такой оптимизации (если конечно эта конструкция у тебя выполняется не десятки миллионов раз). А вот загромождение кода может быть существенным.
Я уже писал по этому поводу в одной из веток, что ко всему надо подходить рационально. Мне почему-то кажется, что у тебя в коде полно более важных мест, оптимизация которых действительно дала бы колоссальный выигрыш в производительности. Начать нужно с основного алгоритма. У большинства новичков происходят тупая проверка на каждом тике всех условий, касающиеся ТС или открытых ордеров. Отсюда и тормоза. Хотя в большинстве случаев достаточно проверять лишь граничные условия, например достижение хаем и лоем определённого значения, либо появление нового бара. И лишь после этого выполнять дальнейшие проверки.
Ну и кроме того, при ресурсоёмких вычислениях нужно задуматься о переносе этих вычислений в DLL. А то сидеть и ждать по 13 минут на грёбанном MQL4 (хотя можно получить тот же результат за 2-3 минуты) как-то ущербно :)
Вообще самый быстрый вариант будет такой:
Впрочем, строчку else result=false лучше совместить с первой строчкой, на скорости это практически не отразится. Да и вообще, если A, B, C и D содержат простые условия (с минимумом арифметических действий, без вызова всяких математических функций и прочих прибамбасов), то особого выигрыша в производительности ты не получишь от такой оптимизации (если конечно эта конструкция у тебя выполняется не десятки миллионов раз). А вот загромождение кода может быть существенным.
Я уже писал по этому поводу в одной из веток, что ко всему надо подходить рационально. Мне почему-то кажется, что у тебя в коде полно более важных мест, оптимизация которых действительно дала бы колоссальный выигрыш в производительности. Начать нужно с основного алгоритма. У большинства новичков происходят тупая проверка на каждом тике всех условий, касающиеся ТС или открытых ордеров. Отсюда и тормоза. Хотя в большинстве случаев достаточно проверять лишь граничные условия, например достижение хаем и лоем определённого значения, либо появление нового бара. И лишь после этого выполнять дальнейшие проверки.
Ну и кроме того, при ресурсоёмких вычислениях нужно задуматься о переносе этих вычислений в DLL. А то сидеть и ждать по 13 минут на грёбанном MQL4 (хотя можно получить тот же результат за 2-3 минуты) как-то ущербно :)
Самый быстрый вариант предложтл Paco
Вы всерьёз считаете, что каждый раз суммировать несколько значений (т.е. выполнять лишние арифметические операции) - это быстрее? В моём варианте проверка заканчивается при первом же совпадении, а в упомянутом вами варианте - только после суммирования всех значений и последующей проверки суммы.
Кроме того, тот вариант требует вычисления ВСЕХ условий заранее. Так о какой быстроте вообще может быть речь. Это самый медленный вариант.
если нужно ускорение, то можно попобовать побитовые операции.
Т.е. все переменные сделать типа int (false=0). Затем побитово A|B|C...>0
если нужно ускорение, то можно попобовать побитовые операции.
Т.е. все переменные сделать типа int (false=0). Затем побитово A|B|C...>0
И никто не проверит предложенные варианты на скорость выполнения?
За основу можно взять скрипт отсюда
Вообще самый быстрый вариант будет такой:
Впрочем, строчку else result=false лучше совместить с первой строчкой, на скорости это практически не отразится. Да и вообще, если A, B, C и D содержат простые условия (с минимумом арифметических действий, без вызова всяких математических функций и прочих прибамбасов), то особого выигрыша в производительности ты не получишь от такой оптимизации (если конечно эта конструкция у тебя выполняется не десятки миллионов раз). А вот загромождение кода может быть существенным.
Я уже писал по этому поводу в одной из веток, что ко всему надо подходить рационально. Мне почему-то кажется, что у тебя в коде полно более важных мест, оптимизация которых действительно дала бы колоссальный выигрыш в производительности. Начать нужно с основного алгоритма. У большинства новичков происходят тупая проверка на каждом тике всех условий, касающиеся ТС или открытых ордеров. Отсюда и тормоза. Хотя в большинстве случаев достаточно проверять лишь граничные условия, например достижение хаем и лоем определённого значения, либо появление нового бара. И лишь после этого выполнять дальнейшие проверки.
Ну и кроме того, при ресурсоёмких вычислениях нужно задуматься о переносе этих вычислений в DLL. А то сидеть и ждать по 13 минут на грёбанном MQL4 (хотя можно получить тот же результат за 2-3 минуты) как-то ущербно :)
Так еще быстрее.
Вспомнил байку:
"На заседании правления компании было 2 вопроса:
1. Решение о строительстве синхрофазотрона.
2. Решение о строительстве велопарковки для сотрудников.
По первому вопросу обсуждение длилось 1-ну минуту,
по 2-му прения продолжались более 2-х часов."