Теория ускорения работы советника при использовании пользовательского индикатора (функция - iCustom) - страница 3

Новый комментарий
 
-Aleks-:
Значит солянка из нужных индикаторов будет работать быстрей, чем использование индикаторов по отдельности - так меньше раз будет запрошена информация о котировках?

Не существенно. Надо следить, чтобы вычисления не дублировались. Если в двух индикаторах предварительные вычисления одинаковые, то стоит объединить их в один. Так просто лепить в один все индикаторы не стоит.

Проблем с запросом котировок не существует. Их не надо запрашивать, они сами приходят. 

 

Пробовал использовать задержку по времени для пересчета индикатора:

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const int begin,
                const double &price[])
  {
 static datetime   prevtime;
  datetime per=15; //задержка секунд
   
   if((TimeCurrent()-prevtime)<per) 
   {
   return(rates_total); //прошло мало секунд - поэтому выходим
   }
 
//--- main cycle  
....................

prevtime=TimeCurrent();
return(rates_total);
 }

  При тестировании на  "OHLСнаМ1" разницы почти нет,  возможно тестирование на "всех тиках" будет проходить быстрее. 

 

мое впечатление как работает iCustom (если за 2 последних месяца ни чего не поменяли)
при вызове индикатора из iCustom
будут рассчитаны все буферы для возможной истории и результаты загнанные в кеш, также будет привязка кеша к параметрам и имени индикатора

если следующий раз вызвать тот же индикатор и те же параметры для второго индексного массива - результат вернется с кеша (+  поправка на новые данные истории)
если вызвать тот же индикатор, но изменить хоть один параметр - происходит полный расчет все буферов для возможной истории и сохранение еще одного кеша, но с привязкой уже к новым параметрам.


Из эксперта можно указать сколько истории надо загрузить, если сделать такой параметр в индикаторе, но при таком вызове надо постоянно передавать одно и то же число - размер истории.
(повлияет на скорость первого вызова iCustom)

Так же можно попытаться убрать расчет ненужных буферов если это возможно, как в самом индикаторе так и через параметр индикатора, как в примере с размером истории
(уменьшит размер кеша - увеличит скорость расчета)

 

Всем спасибо за информацию. 

Хочу уточнить, если в индикаторе с 5 граф буферами использовать не графический буфер, а обычный массив - вывод данных сделать через один графический буфер, как я предложил, то скорость работы советника при оптимизации будет больше, так как памяти для индикатора будет выделено меньше, а соответственно и время на работу с ней будет тратиться меньше?

Если происходит оптимизация и настройки индикатора не меняются на каждом из проходов, то происходит ли перерасчет индикатора? 

 
-Aleks-:

Всем спасибо за информацию. 

Хочу уточнить, если в индикаторе с 5 граф буферами использовать не графический буфер, а обычный массив - вывод данных сделать через один графический буфер, как я предложил, то скорость работы советника при оптимизации будет больше, так как памяти для индикатора будет выделено меньше, а соответственно и время на работу с ней будет тратиться меньше?

Если происходит оптимизация и настройки индикатора не меняются на каждом из проходов, то происходит ли перерасчет индикатора? 

Буфер - это и есть массив, только удобный для отображения данных.

При оптимизации индикатор рассчитывается каждый раз заново. 

 
komposter:

Буфер - это и есть массив, только удобный для отображения данных.

Я понимаю, что массив, но массив для расчета индикатора может быть гораздо меньше - часто динамичным.

К примеру в истории 1000 баров - пользовательский индикатор отрисовывает 3 SMA - 5/8/10.

При стандартном варианте у нас будет забит графический буфер на почти 3000-10-8-5

А если использовать мой метод, то: 

для расчета SMA(5) нужен массив размером (извиняюсь за терминологию) в 4 бара 

для расчета SMA(8) нужен массив размером (извиняюсь за терминологию) в 7 баров 

для расчета SMA(10) нужен массив размером (извиняюсь за терминологию) в 9 баров 

и графический массив в 1000 баров, в итоге нужно занимать память 1000+4+7+9 так как массивы будут просто перезаписываться.

Где я не прав? 

 
-Aleks-:

Всем спасибо за информацию. 

Хочу уточнить, если в индикаторе с 5 граф буферами использовать не графический буфер, а обычный массив - вывод данных сделать через один графический буфер, как я предложил, то скорость работы советника при оптимизации будет больше, так как памяти для индикатора будет выделено меньше, а соответственно и время на работу с ней будет тратиться меньше?

Если происходит оптимизация и настройки индикатора не меняются на каждом из проходов, то происходит ли перерасчет индикатора? 

имхенько, важнее понимать, что при повторном вызове индикатора не происходит его повторная загрузка в сегмент (Overlay) памяти. По сравнению с этим все прочее - семечки. 
 
-Aleks-:

Я понимаю, что массив, но массив для расчета индикатора может быть гораздо меньше - часто динамичным.

К примеру в истории 1000 баров - пользовательский индикатор отрисовывает 3 SMA - 5/8/10.

При стандартном варианте у нас будет забит графический буфер на почти 3000-10-8-5

А если использовать мой метод, то: 

для расчета SMA(5) нужен массив размером (извиняюсь за терминологию) в 4 бара 

для расчета SMA(8) нужен массив размером (извиняюсь за терминологию) в 7 баров 

для расчета SMA(10) нужен массив размером (извиняюсь за терминологию) в 9 баров 

и графический массив в 1000 баров, в итоге нужно занимать память 1000+4+7+9 так как массивы будут просто перезаписываться.

Где я не прав? 

Если нужно значение на одном баре, то буфер действительно не нужен. Как и индикатор ;)

А если нужно значение индикатора на каждом баре, то часто экономнее будет рассчитать все, а потом досчитывать только новый бар.
И далеко не все алгоритмы такие простые, как SMA, их просто не получится рассчитать "для 5-ти баров". Посмотрите хотя бы зиг-заг.

Больше всего меня смущает, что вы не пробуете применять полученные ответы на практике. Такое ощущение, что и задачи практической нет, только теоретические изыски.
Тогда я не понимаю, зачем принимаю в этом участие.

 

МТ4, кстати, прекрасно справляется с расчетом только части истории и не съедает память под весь буфер, если цикл идет по последним 1000 барам (даже если "в окне" - 50000).

А вот в МТ5 я с этой проблемой столкнулся - память выделяется под все 50000 баров, даже если считать только последние 100. 

 
komposter:

Если нужно значение на одном баре, то буфер действительно не нужен. Как и индикатор ;)

Почему же на одном баре? Речь шла лишь о том, что для расчета значения индикатора редко требуется знание всех его же показателей за всю историю времени. Поэтому и написал, что буфера (массивы) будут использоваться только для расчета, а вот результат расчета 3х МА будет сводно храниться в одном графическтом буфере.

Касаемо Zig-zag  - это сейчас для меня головная боль - требуется ряд ответов, но я открою отдельную тему.

komposter:

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

Тогда я не понимаю, зачем принимаю в этом участие.

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

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


komposter:

МТ4, кстати, прекрасно справляется с расчетом только части истории и не съедает память под весь буфер, если цикл идет по последним 1000 барам (даже если "в окне" - 50000).

А вот в МТ5 я с этой проблемой столкнулся - память выделяется под все 50000 баров, даже если считать только последние 100. 

Печальный факт для пятерки, а разработчики не поясняют сакральный смысл сего?

123456789
Новый комментарий
Причина обращения: