Обсуждение статьи "Уменьшаем расход памяти на вспомогательные индикаторы"

[MetaQuotes]

Опубликована статья Уменьшаем расход памяти на вспомогательные индикаторы:

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

Автор: Andrew

[Mykola Demko]

Подход понятен. Но вот смущает актуальность задачи.

При том что 64-битная система поддерживает огромные объёмы оперативы, актуальность задачи как то меркнет. Да даже 32-бит с его 3Гб вполне тянет такие размеры памяти какие вы экономите. Ведь как ни крути а память при загрузке новых индикаторов растёт линейно, а значит 48Мб больше или меньше для современных компов семечки.

Ладно, предположим что задача актуальна (согласен что есть люди которым это важно). Но задумайтесь, задача экономии памяти напрямую идёт в разрез с задачей быстродействия.

Так что на этот момент тоже нужно обращать внимание.

Насколько мне с моей колокольни видно, MQ борятся за быстродействие и именно тут сконцентрированы все усилия. 

Если же вам нужно сэкономить ресурсы памяти на нерисуемых индикаторах то просто перенесите код индикатора в советник. Тут у вас будет полный контроль над выделяемой памятью. За одно можно будет сэкономить на получении однотипных данных. Многие индикаторы запрашивают одни и те же данные каждый для своей обработки над ними. Получив данные один раз можно будет не обращаться к ним в последующем.

Теперь совместим обе задачи быстродействие и объём памяти. Большинство нерисуемых индикаторов занимается обсчётом последнего бара, на это указывает встроенные механизмы блокировки пересчёта всего массива. Получается что в советнике вообще можно будет выделять (ну например на расчёт машки периодом 153) 154 ячейки памяти при такой экономии памяти быстродействие будет не хуже чем в обычном индикаторе.

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

[[Удален]]

Согласен, быстродействие это основной приоритет и экономить память нет смыла (если конечно не юзается памяти больше 1Gb, что маловероятно).

[ds2]

Urain:

Подход понятен. Но вот смущает актуальность задачи.

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

Да даже 32-бит с его 3Гб вполне тянет такие размеры памяти

Если торговать на большом количестве пар, то не тянет, в том-то и дело.

Терминал, кстати, не может выделить памяти больше 2 Гб (в сумме: оперативная + виртуальная). В моих экспериментах он закрывался на этой отметке.

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

Ладно, предположим что задача актуальна (согласен что есть люди которым это важно). Но задумайтесь, задача экономии памяти напрямую идёт в разрез с задачей быстродействия.

Не всегда. В статье, вот, как раз большинство методов не снижают быстродействия.

Если же вам нужно сэкономить ресурсы памяти на нерисуемых индикаторах то просто перенесите код индикатора в советник.

Советник, запрашивающий от индикаторов лишь последний бар, - это уже другой класс программы, нежели рассмотренный в статье. И не всегда возможно/удобно заменить одно на другое.

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

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

[Mykola Demko]

ds2:

Проблема индикаторов в том что каждый работает в своём потоке и для работы должен в самом потоке хранить все необходимые данные.

Данные между потоками копируются через CopyBuffer(). Но вот незадача, получить данные из потока можно, а вот передать их туда нет. Поэтому строить могоступеньчатые индикаторы в которых несколько экземпляров одного индикатора получают одни и те же предобработанные данные не получится. А ведь именно в этой плоскости могут лежать большие возможности по оптимизации вычислений.

Думаю если MQ решат эту задачу, работа с индикаторами станет более удобной и гибкой. Сейчас же данные можно только передать в качестве внешних параметров и только при запуске потока.