В какой-то момент достали торможения MQL4 в тестере и оптимизаторе, пришлось переписать советники и индикаторы исходя из худших подозрений о программной архитектуре. Всё значительно ускорилось, что с одной стороны радует, а с другой вгоняет в некоторую тоску-печаль :-(
Получается что по быстродействию от самого быстрого к самому медленному, причём разница ощутима:
- обращения к глобальным и локальным скалярным переменным
- обращения к элементам фиксированных массивов
- обращения к скалярным элементам структур и классов
- косвенные обращения ( оператор "." видимо частично реализуется в рантайме)
- обращения к элементам динамических массивов
- вызов встроенных функций
- вызов функций пользователя, причём чем больше аргументов, тем дольше вызывается
- вызов методов классов
- вызов виртуальных методов
- операторы new, delete
- вызов внешней функции из DLL
- вызов iCustom
Если нужна быстрая оптимизация, высокая скорость работы и низкая нагрузка на VDS, то выходит антитеза современному программированию:
- чем меньше ООП тем лучше, для скальперов слово "class" вообще противопоказано
- сеттеры, геттеры и виртуальные функции - враги скорости. Все члены классов должны быть публичны, а виртуальных методов минимум.
- вместо динамических массивов лучше использовать фиксированные с большим размером
- динамических структур (списков/деревьев/графов) лучше избегать, там внутри new/delete, разименовывания и косвенная адресация
- максимально использовать глобальные переменные и как можно меньше таскать данных через аргументы
- функции и методы классов укрупнять, даже за счёт дублирования кода и copy-paste
- DLL либо не использовать вовсе, либо реализовывать всю логику+математику советника/индикатора в одном вызове
- часто вместо iCustom (прочих iXXX тоже) быстрее работают аналогичные вычисления в текущем потоке
торжество глобальных данных и спагетти-кода
PS. Вышесказанное относится к MQL4, за малым объёмом собственного кода на 5-ке про неё пока не скажу, но не вижу предпосылок чтобы ей быть быстрее.
