ФорумРазделы

Ошибка выделения памяти - страница 2

Новый комментарий
Svinozavr >>:

Зачем вам ВСЕ значения по всей истории в советнике?

Алгоритм такой. Ну все конечно не нужны, но надо тысяч несколько значений с каждого ТФ.
Svinozavr >>:
По коду. Ресайз лучше делать не на каждом тике, а только на новом поступившем баре соотв. тф. На память это влиять, по идее, не должно, но на быстродействие - точно.

Именно так и делается. При поступлении нового бара на ТФ делается ресайз массива этого ТФ

Svinozavr >>:

Еще. Если вы перенесете в индикаторы то, что вы делаете сейчас в советнике, то проблема, скорее всего, будет устранена.

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

IgorM >>:


#define num 60 //количество элементов в массиве, 60 -вроде как 60 сек или мин :)
static double Mass[num];

......... . .......
ArrayCopy(Mass,Mass,0,1,WHOLE_ARRAY); //сдвигаем массив на одну позицию
.......... .......... ...

интересно, при этом весь массив реально переписывается, или в правду лишь сдвигается?

если переписывается весь, то смысл то какой? производительность упадет

lusp >>:
Алгоритм такой. Ну все конечно не нужны, но надо тысяч несколько значений с каждого ТФ.

Ой ли, уверены? Нет, я не говорю, что так не может быть, но, как правило, если не требуется отрисовки из советника значений, нужно немного.

Именно так и делается. При поступлении нового бара на ТФ делается ресайз массива этого ТФ

ок.

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

Механизм выделения памяти.

А быстродействие советника при наличии всех необходимых данных в нем самом возрастает в разы, т.к. не нужно использовать не самую быструю функцию iCustom.

Нет. Операции с ресайзом, копированием и пр. с массивами на порядок медленнее, чем обращение из советника к буферам индикатора.

vasya_vasya >>:

интересно, при этом весь массив реально переписывается, или в правду лишь сдвигается?

если переписывается весь, то смысл то какой? производительность упадет


думаю, что реально сдвигается, т.к. сдвиг массивов данных - это аппаратная возможность процессора (ассемблерная команда MOV AX, VALUE [BX][DI] ), думаю разработчики MQL много встроенных функций реализовали с максимальной производительностью
ЗЫ: а что Вам мешает проверить это на простом скрипте? - храните в массиве (1000 эл-в) котировки Ask и считайте среднее арифметическое последних 1000 котировок и выводите в виде Comment на график, при этом каждый раз сдвигайте массив
Svinozavr >>:

Нет. Операции с ресайзом, копированием и пр. с массивами на порядок медленнее, чем обращение из советника к буферам индикатора.

Я как раз и стал переделывать систему, вводя все индикаторы в советник, что бы уйти от iCustom. Возможно единичное обращение к ней будет работать и быстрее, чем ресайз. Но когда на каждом тике надо несколько тысяч значений индикатора, да не одного, а ресайз в худшем случае делается раз в минуту, то выгода очевидна. После такой трансформации быстродействие советника меня стало удовлетворять, а вот с памятью получилась засада

IgorM >>:


думаю, что реально сдвигается, т.к. сдвиг массивов данных - это аппаратная возможность процессора (ассемблерная команда MOV AX, VALUE [BX][DI] ), думаю разработчики MQL много встроенных функций реализовали с максимальной производительностью
ЗЫ: а что Вам мешает проверить это на простом скрипте? - храните в массиве (1000 эл-в) котировки Ask и считайте среднее арифметическое последних 1000 котировок и выводите в виде Comment на график, при этом каждый раз сдвигайте массив

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

double array[4]={0,1,2,3};
ArraySetAsSeries(array,true);
ArrayResize(array,ArrayRange(array,0)+1);
array[ArrayRange(array,0)-1]=-1;
ArraySetAsSeries(array,false);
ArrayResize(array,ArrayRange(array,0)-1);
lusp >>:

Я как раз и стал переделывать систему, вводя все индикаторы в советник, что бы уйти от iCustom. Возможно единичное обращение к ней будет работать и быстрее, чем ресайз. Но когда на каждом тике надо несколько тысяч значений индикатора, да не одного, а ресайз в худшем случае делается раз в минуту, то выгода очевидна. После такой трансформации быстродействие советника меня стало удовлетворять, а вот с памятью получилась засада


Если вы динамически не меняете параметров индикатора из советника, то обращение быстрое, т.к. в этом случае iCustom не пересчитывает индикатор по истории, а работает только как ссылка на ячейку в его буфере. Но если тыщи на каждом тике... мдя..

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

Почти уверен, что все можно было бы решить легче. Хотя... всяко м.б. )))

12
Новый комментарий