Когда сделал кубиком трейл-стоп на основании кода стандартного трейла, ощутил очень сильное влияние скорости работы трейла на скорость работы скрипта, точнее на скорость оптимизации скрипта.
Скорость уменьшалась в разы.

Сделал замеры скорости выполнения стандартного трейла и своего, посмотрел, что вроде и дольше мой трейл выполняется, но речь идёт о ничтожно малых величинах.

Попытался попереписываться с поддержкой, получил пару отписок.

Выкладываю для истории на форум, может когда-нибудь это к чему-нибудь приведёт.

Я, после десятков сделанных кубиков, всё равно остаюсь при своём мнении, что данная ситуация с трейлом - ненормальна.
И она не позволяет нормально работать с кастомными трейлами, нужно наворачивать десятки кубиков вместо одного.

Просто сейчас сделал ещё один вариант трейла, и с начальным стопом и с трейлом по теням баров, но при всей несложности алгоритма и скрипта 5000 прогонов затянулись на бог знает сколько.

Делать подобный вариант с привязкой к ATR даже смысла не имеет, там ещё чуть сложнее и будет бесконечно долго.

приходится проявлять чудеса оптимизации

Важно чтобы в реале трейлы отрабатывали нормально, а при оптимизации можно и потерпеть, и повыкручиваться кто во что горазд..

Чего тут говорить, в стандартном трейле до сих пор сидит недочет, про который Вито уже не раз писал в своей ветке, да и исправленный код уже выкладывал...
Вот дождемся от Вито возможности использовать расчетную цену, и в моих скриптах почти не останется стандартных блоков