A question about the relationship between indicator lines and terminal lag

I have 4 MT4 terminals, with 15 charts per terminal. I've been updating my trading system lately. One of the measures I took was to reduce the number of indicators on each chart, thinking that this would make my system snappier. To this end, I coded one indicator to have multiple buffers and display multiply lines.

After several days of coding it, I deployed it on my terminals and was disappointed to discover that one indicator displaying multiple lines makes my terminal very sluggish when there are a 4 terminals open. My terminals were much happier having several indicators per chart, each displaying one line.

I researched the subject and discovered that indicators share a common thread with MT4s GUI. Hence, if the indicators exert their own load, the MT4 terminal GUI will itself become sluggish. I ran some tests on my indicator and discovered that not displaying any lines speeds up the Terminal, meaning the problem appears to have something to do with rendering (and not with anything in the OnCalculate or OnTimer functions). I tried reducing the bar-count length of the lines (from 5000 to 3000) but this did not have appreciable effect. GUI was still sluggish.

Would someone fill me in on the technical details regarding the above problem? What is it about one indicator displaying multiple lines that makes the computational cost of this higher than multiple indicators each displaying one line? And what is it about the rendering of lines in this situation that causes my terminals to lag?

shoxie:
I have 4 MT4 terminals, with 15 charts per terminal. I've been updating my trading system lately.

Forum on trading, automated trading systems and testing trading strategies

MT4 consuming very high CPU/power usage

Fernando Carreiro, 2021.07.10 03:19

Probably one or more of the indicators you are using is inefficient and/or badly coded and consuming too much CPU and RAM.

Start with a completely clean slate with completely empty charts and check each indicator one by one to see which one is consuming the most CPU.

If you are using Multi-currency or Multi-time-frame Indicators, they are usually the ones that are least efficient.

Also, clean out log files to release disk space.

Forum on trading, automated trading systems and testing trading strategies

MT4 consuming very high CPU/power usage

William Roeder, 2021.07.10 14:07

  1. I have (MT4) 60+ charts with nine (9) indicators (including one MTF) open on my (4 core) laptop, averaging 15% CPU, 109 MB RAM, 10 MB/s disk. 2020.06.19

  2. It is likely, what Fernando said, a badly coded indicator. Reduce Tools → Options (control+O) → Charts → Max bars in chart to something reasonable (like 1K.)


Ryan L Johnson #: Probably one or more of the indicators you are using is inefficient and/or badly coded and consuming too much CPU and RAM.

I would love if this were true. The thing is that the functionality of the indicator itself is so simple that there's very little that needs to be done to optimize it. It's an indicator that plots multi-timeframe moving averages on the chart. I just give it various options, such as which timeframe MAs to plot, and it does that. So I end up with for example, the 100 and 200 Daily MAs, and the 100 and 200 Weekly MAs.

Besides this, I actually turned off the functionality where new values are calculated, just to test if the issues was with the code in OnCalculate and OnTimer. It didn't make a difference. I also reduced the number of bars for which values were calculated for the indicator line. Didn't really make a difference. The only thing that made the difference was actually not displaying the lines on the chart. 

An MT4 developer with knowledge of the internals of the terminal might know something about an issue so specific. Again, it's worth remembering that in MT4, literally all indicators share a common programming thread with the terminal's UI. I think the purpose of this is to have more seamless rendering of indicators between timeframe changes for example. But the downside is if the indicators impose too great a load, the UI slows down as well. 

BTW, my terminals do NOT consume max CPU and RAM. In fact, I'm disappointed by how little demand they make on my system's available resources. The problem appears to be a bottleneck within MT4 itself. 

shoxie #:
[My]y terminals do NOT consume max CPU and RAM. In fact, I'm disappointed by how little demand they make on my system's available resources. The problem appears to be a bottleneck within MT4 itself.

Although I moved on to MT5 many years ago (I'm assuming that there's a valid reason that you haven't), I do recall that graphical objects can be burdensome on MT4, and even MT5 in extreme cases. I don't believe that is the issue in your case (see below).

Regarding the fact that multiple indicators worked without issue, and the fact that consolidated multi-line buffer indicators are burdensome, I also recall that indicators run sequentially in MT4. When you had a relatively simple setup consisting of single line buffer indicators, one would run, then another would run, and so on. I'm not so sure that the word, "simple," and the phrase, "multi-timeframe moving averages," go together so well. I would not call synchronizing rates from a range of different timeframes "simple." I don't know how you coded your consolidated indicator(s), but it's possible that you may have inadvertently written some race conditions that make buffers compete with each other.

By the way, we are in the default MT5 forum here. @Alain Verleyen, please move this thread to the MT4 subforum. Thank you.
i could be wrong, i think that i remember there also being a max of 8 threads, per terminal.
Michael Charles Schefe #:
i could be wrong, i think that i remember there also being a max of 8 threads, per terminal.

Thanks for prefacing your statement with a grain of salt:

"All indicators work in the graphic interface thread."

Program Running - MQL4 programs - MQL4 Reference
Program Running - MQL4 programs - MQL4 Reference
  • docs.mql4.com
Program Running - MQL4 programs - MQL4 Reference
Michael Charles Schefe #:
i could be wrong, i think that i remember there also being a max of 8 threads, per terminal.
Ryan L Johnson #:
but it's possible that you may have inadvertently written some race conditions that make buffers compete with each other.
Thanks for the responses. Food for thought. But here's a question: I get why indicators would get in each others' way within a terminal; But what is the mechanism by which one terminal makes another terminal sluggish, even when all of them put together don't use up maximum CPU and RAM? That's the mystifying situation I face.
shoxie #:
Thanks for the responses. Food for thought. But here's a question: I get why indicators would get in each others' way within a terminal; But what is the mechanism by which one terminal makes another terminal sluggish, even when all of them put together don't use up maximum CPU and RAM? That's the mystifying situation I face.

You're welcome. Thank you for being personable in your requests.

Assessing your situation by the information that we have:

"My terminals were much happier having several indicators per chart, each displaying one line"...

how can we deduce that one terminal causes another terminal to be sluggish? As everything was fine until you changed the overall setup of your indicators, I suspect that change to be the cause. Does that make more sense now?
These suggestions are of no use to me. Is there a knowledgebase somewhere describing the inner mechanics of rendering indicator lines, what threads are shared, the queuing process, etc? That would shed some light on the matter, and I could get somewhere.
shoxie #:
These suggestions are of no use to me. Is there a knowledgebase somewhere describing the inner mechanics of rendering indicator lines, what threads are shared, the queuing process, etc? That would shed some light on the matter, and I could get somewhere.
Once upon a time... there were threads on here that discussed this "at length", so search and search and search, and maybe you will find those; but i think it is more likely that they were deleted soon after the invention of mt5, as their information might be considered to not be applicable anymore. good luck. However i agree with ryan, i think the obvious fix is to revert all your changes to the original(s).
Michael Charles Schefe #:
Once upon a time... there were threads on here that discussed this "at length", so search and search and search, and maybe you will find those; but i think it is more likely that they were deleted soon after the invention of mt5, as their information might be considered to not be applicable anymore. good luck. However i agree with ryan, i think the obvious fix is to revert all your changes to the original(s).

Thanks. I will keep looking for workarounds. One workaround is to put each terminal in its own Hyper-V VM, in Windows. This way there is NO way for one terminal to interfere with another.