Terminal hanging (multi-TF / multi-symbol)

New comment
 

I've been trying to get to the bottom of terminal hangs after removing multi-timeframe multi-symbol indicators.

This issue can be replicated (on my terminal) by applying this very simple script.

About 5 seconds after script execution, the terminal will hang for 1-2 minutes.

I would appreciate it if someone could confirm/deny this behaviour on their system, and let me know which build they are running.

Many thanks! 

#property strict

void OnStart()
  {
   for(int i=0; i<SymbolsTotal(true); i++)
     {
      string sym=SymbolName(i,true);
      double ma;
      ma = iMA(sym,PERIOD_M1, 25,0,MODE_EMA,PRICE_CLOSE,0);
      ma = iMA(sym,PERIOD_M5, 25,0,MODE_EMA,PRICE_CLOSE,0);
      ma = iMA(sym,PERIOD_M15,25,0,MODE_EMA,PRICE_CLOSE,0);
      ma = iMA(sym,PERIOD_M30,25,0,MODE_EMA,PRICE_CLOSE,0);
      ma = iMA(sym,PERIOD_H1, 25,0,MODE_EMA,PRICE_CLOSE,0);
     }
  }
 
honest_knave:

This issue can be replicated (on my terminal) by applying this very simple script.

I can't replicate it using your script - and I can't reliably and repeatedly replicate it using anything - but I have seen similar things which appear to be related to historic data access via iMA(), iOpen() etc. Started with build 745, if not earlier, and still the case in the latest beta 845. Seems to be made worse by function calls involving data which hasn't been downloaded yet. I get problems something between very infrequently and never if the history data in the platform is fully complete and up to date.
 
It might be memory issue. Every i-reference to another symbol&timeframe consumes unbelievable amount of memory, which does not release until the script/indicator unloads.
 

Thanks very much for the replies jjc and Ovo.

This particular problem never manifests itself during the operation of the indicator/script... it only happens shortly after unloading. I can run something for a day or more with no adverse effects. But as soon as I come to remove it... Everything in deinit runs and there is usually about a 5 second delay before the hang kicks in. The hang resolves itself after about 1-2 minutes.

Which makes me think MT4 is having some issues releasing the memory?

 
honest_knave:

This particular problem never manifests itself during the operation of the indicator/script... it only happens shortly after unloading.

Ditto. For me, it's particularly unloading in the context of switching profiles.

 

honest_knave:

Which makes me think MT4 is having some issues releasing the memory? 

It feels to me - and I can't quantify or replicate it into something more than a feeling - like some sort of memory-locking issue; some sort of race condition where there's something like code A waiting for access to the memory and code B waiting to release it.

 
Reduce Max Bars on chart. Releasing memory that has been paged out takes time.
 

Thanks again for the replies.

Dropping the max bars on chart does help, but what concerns me more is that this seems to have become an issue mainly in the later builds (as jjc also points out). Has something changed in the way MT4 releases the memory?

In the absence of confirmatory print statements, am I correct in surmising that every call to iXXX is the same as an iCustom call? i.e. 1 double per bar per separate instance called.

 

I've been running a simple memory logger to see if memory really is the problem:

TerminalInfoInteger(TERMINAL_MEMORY_USED)


When the multi-TF multi-symbol stuff gets added, the memory increase is minimal in the big scheme of things.

However, come unload time it will still hang 1-2 minutes. 

Max Bars in Chart = 5000

Something else is certainly amiss here.

 

Here is the memory usage (M1 chart, diamonds are memory usage peaks during the minute).

First white line is when the multi-TF / multi-symbol indicator gets added to a newly opened chart.

I let it run for a few minutes. As you can see, the memory increase was nominal.

I then closed the chart immediately after drawing the second white line. The terminal freezes for 1 minute, then memory spikes up after the chart has been closed.

Interestingly, memory usage never returns back to it's original range.

 

New comment
Reason: