Потребление памяти терминалом - страница 4

 
komposter:
У меня не воспроизводится. Может, у вас что-то другое "оживает"?
Может видео записать и здесь выложить? Не уверен, что это кому-то кроме нас интересно.
 
mrProF:

А разве кэш не вытесняемый? Ну тоесть когда память нужна, урезаем кэш, память не нужна, раздуваем?

И еще, добавление последующих объектов ведь не съедает столько же памяти, это скорее начальная инициализация примочек, иначе бы и пару тысяч объектов не создать. (2000 х 5Мб = 10Гб) в своп бы глубоко ушли

1. Не знаю

2. Мне нужно запустить 10 индикаторов, создающих по 5 объектов-меток в своих подокнах. Почему я должен платить 100 Мб "за того парня" (который строит 200000 объектов)?

 
avoitenko:
Может видео записать и здесь выложить?
Я не сомневаюсь в правдивости ваших слов, просто отметил, что у меня не так. Наверное, от чего-то еще зависит.
 

Собственно, реальная проблема в том, что благодаря этому кэшу терминал в 3-мя индикаторами на графике начинает подвисать.

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

 

Только, пожалуйста, не надо мне (и всем пользователям моих кодов) советовать перейти на x64 и купить побольше памяти.

Документация по MQL5: Операции с графиками / ChartIndicatorAdd
Документация по MQL5: Операции с графиками / ChartIndicatorAdd
  • www.mql5.com
Операции с графиками / ChartIndicatorAdd - Документация по MQL5
 
komposter:

Только, пожалуйста, не надо мне (и всем пользователям моих кодов) советовать перейти на x64 и купить побольше памяти.

А почему бы и не перейти на x64? Лично мне памяти не жалко, лишь бы всё работало.
 
avoitenko:
А почему бы и не перейти на x64? Лично мне памяти не жалко, лишь бы всё работало.
Вопрос в другом. Я же не могу перевести на х64 и всех своих клиентов?
 
komposter:

2. Мне нужно запустить 10 индикаторов, создающих по 5 объектов-меток в своих подокнах. Почему я должен платить 100 Мб "за того парня" (который строит 200000 объектов)?

Это легко проверяется. Создайте 10 индикаторов подобных приведенному ранее и набросьте их на чарт. Около 6 Мб - и это исключительно потребление самого чарта, к индикаторам не относится. Если одновременно программно работаете с 10-тью чартами, то действительно резерв памяти будет около 60 Мб. Это много?

Собственно, реальная проблема в том, что благодаря этому кэшу терминал в 3-мя индикаторами на графике начинает подвисать.

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


 
antt:

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

Действительно, 2-й и все последующие индикаторы столько не съедают.

Но почему тогда это происходит при создании объекта? Зачем объекту буферы чарта?

 

В 4-ке можно было ограничить глубину обсчитываемой истории (не обрезая отображаемую), и проблем с памятью не возникало.

А тут придется изобретать что-то новое. 

Документация по MQL5: Основы языка / Операторы / Оператор создания объекта new
Документация по MQL5: Основы языка / Операторы / Оператор создания объекта new
  • www.mql5.com
Основы языка / Операторы / Оператор создания объекта new - Документация по MQL5
 
komposter:

Действительно, 2-й и все последующие индикаторы столько не съедают.

Но почему тогда это происходит при создании объекта? Зачем объекту буферы чарта?

Объект программа создает на чарте? В абсолютном большинстве случаев одним объектом дело не ограничивается, программа и далее работает с чартом. Поэтому память резервируется из расчета на активную работу.
 
antt:
Объект программа создает на чарте? В абсолютном большинстве случаев одним объектом дело не ограничивается, программа и далее работает с чартом. Поэтому память резервируется из расчета на активную работу.

Теперь все ясно, индикатор с одним объектом - исключение. С этим согласен.

Будем думать. 

Причина обращения: