Features of the mql5 language, subtleties and tricks - page 131

 
fxsaber:

Memory release is the only reason.

What kind of memory? If redundant, thenreserve_size=-1 is sufficient, as has already been said. Only the person there obviously got something wrong with the speed measurements (incorrect test conditions, I guess)

 

I have noticed an interesting possibility, which I will call indicator recursion.

When you can calculate an indicator from itself:

handle=iMA(_Symbol,_Period,per1,0,MaMethod,PriceBase);  
for(int i=0;i<N;i++) handle=iMA(_Symbol,_Period,per2,0,MaMethod,handle);

It may be useful for indicator fans...

In case this topic has already been covered, repetition is the mother of learning.

To demonstrate this feature, I have specially written an indicator in QB.

 
Nikolai Semko:

I have noticed an interesting possibility, which I will call indicator recursion.

When you can calculate an indicator from itself:

It may be useful for indicator fans...

In case this topic has already been covered, repetition is the mother of learning.

To demonstrate this feature, I have specially written an indicator in QB.

Yes... I didn't think it was a special feature. Once I needed it, I just wrote it that way, just made different variable names for the handles. Thought everyone used it when they needed to...

 
Alexey Viktorov:

Yes... I didn't think it was a feature. Once I needed it, I just wrote it like that, but with different variable names for handles. Thought everyone used it when they needed to...

I only thought of putting it in a loop now. You can reproduce the indicator 100 times, but there's only one handle.

 
Nikolai Semko:

I have only just thought of putting it into a loop. You can reproduce the indicator at least 100 times, but there is only one handle.

It's not a single handle, you have one variable. You have lost the values of the previous handles. And how do you close them?

 
Alexey Navoykov:

It's not a single handle, you have one variable. You have lost the values of the previous handles. And how do you close them?

Well...

It consumes a lot of memory. Really, only by changing TF you can free the internalindicator buffers that are not needed anymore. ))

There is no way to screw in ArrayFree.

 
Nikolai Semko: Really, only by changing the TF you can release the internalindicator buffers that are not needed. ))

There is no way to attach ArrayFree.

Changing the TF creates a new copy of the indicator, and destroys the old one

 
Igor Makanu:

changing the TF creates a new copy of the indicator and destroys the old one

Well that's understandable.

I just looked at the memory usage when loading at the maximum settings of my indicator (sliders to the right to the edge). From 50 MB memory has increased to somewhere around 400 MB. But when I brought the indicator back to the minimum (sliders to the left), the memory still hangs at 400 Mb.

It means that all 100 calculated indicators are hanging in the memory, though they are not used.
Changing TF clears it.

 
Nikolai Semko:

Well, that's understandable.

It's just that I looked at the memory usage during boot according to the maximum settings of my indicator (sliders to the right to the edge). From 50 MB memory increased to somewhere around 400 MB. But when I brought the indicator back to the minimum (sliders to the left), the memory still hangs at 400 Mb.

So, all 100 calculated indicators are hanging in the memory, although they are not used anymore.
Change of TF clears it.

Wrap it in the class calculating indicator - bind buffers to the class fields

 
Igor Makanu:

wrap the indicator calculation in a class - bind the buffers to the class fields

Yes, I'll have to give it a try. Thank you.
Reason: