MT4 or MT5 slow or freezes? 3 reasons and how to fix
13 minute read
Is your MT4 or MT5 application slow, lagging or freezing? Does the chart have a delayed reaction to clicks, or does the application freeze every few seconds? This article will cover 3 common reasons and how to fix them.
If MT4 or MT5 is running slow or freezes, the reason is almost always because of code inside a custom indicator, which is doing one of the following:
- An indicator is running a loop over too many bars, too often; or repainting.
- Something has generated too many graphical objects on a chart.
- An indicator makes a slow system call too often.
If you’re a trader using indicator products, you place trust in developers that software will run smoothly and won’t crash your system.
If you’re a developer, there’s a responsibility to know the technical quirks of MT4 and MT5 so that you can build stable, mission-critical indicators and expert advisors (EAs).
However, with indicators and EAs being developed by people of hugely varying experience levels, and lots of MT4 and MT5 quirks, you’re bound to install an indicator or EA that causes the application to become slow or freeze. When this happens, you should use the methods in this article to quickly find the culprit.
If you’re a trader reading this article to fix your lag, read on for instructions.
If you’re a developer, read on for some insights into MT4/MT5 quirks.
Let’s now go through each of these 3 common causes and their fixes.
1. A slow indicator, especially one that repaints
The most common cause of a slow, frozen or lagging MT4 or MT5 terminal is a custom indicator that runs very slowly, holding up the entire application.
Looking deeper, the most common specific reason is that an indicator’s code contains a loop that goes over a larger and larger number of bars as time goes on.
One extremely common situation where this happens is in repainting products that recalculate past outputs on every tick. This is sometimes an accident.
The jargon ‘repainting’ can mean a few different things, but in general describes a behavior where an indicator changes its past advice to the trader after already having given it – usually by scrolling back to old signals and redrawing them.
Another deeper reason is that the code contains an algorithm that accumulates a worse and worse running-time with every tick. For example, running some math over all available bars which increases over time, rather than a constant period.
This is sometimes an issue in algorithm design, which means it must be fixed by a developer who knows the original goals of the code and how to rewrite it in a more performant way.
There are also some types of slow algorithms that can only be made performant by special experts. For example, if a standard deviation is computed using the simple school formula, it will be very slow – for a performant version, we need to use a special version of the algorithm that mathematicians have made for computers.
We could summarize to say that slow indicators tend to have O(n) or O(n²) running time complexity for their OnCalculate
function, where n is a large or growing dataset – usually bars. In general, indicators that run with an acceptable speed need to be faster than this – i.e. constant complexity.
As a trader or user, you need not worry about this technicality. You just need to identify a very slow indicator and, if possible, find a replacement.
An indicator with this type of problem might also run smoothly at first, but then get slower and slower, lagging the MT4 or MT5 interface after running for a few hundred chart bars.
How to identify a slow indicator
Start by identifying all indicators that are running. Each chart has an Indicators List. To see it, right-click on an open chart and select ‘Indicators List’.
If the option isn’t there, then there aren’t any indicators running on that chart, so you can move on to check the next chart.
Run it in the Strategy Tester
For every indicator that you find in the Indicators List, check it individually for slowness in the Strategy Tester as follows:
- Do a test-run of an indicator using the ‘Every tick’ model at max speed. An offending indicator will make the Strategy Tester lag or stutter.
- For a baseline comparison, do the same test-run on a stock indicator like RSI. This will give you a feel for what’s very fast.
- You’ll find that the test-run for an acceptable indicator (medium-to-fast) carries on with a consistent speed. Whereas, a buggy indicator could make the chart become slower and slower, or even freeze the test-run.
Drill down to involved indicators
Once you identify an indicator that’s drastically slower than any other, it may still not be the actual culprit.
If this indicator is using signals from other involved indicators, you need to drill down into each of the involved indicators to find the bottleneck. This is because if an indicator lags, then anything that uses it will also lag.
So, drill down as best you can, until you find the slow indicator in the chain. We say ‘as best you can’, because it’s not easy to identify involved indicators; they don’t appear on the Indicators List. That is, if an indicator or EA is using some involved indicators internally, they won’t appear on the Indicators List.
It’s sometimes possible to identify involved indicators by looking at the Experts log:
However, the Experts log will not always log all involved indicators. So, again, drill down as best you can to the final known slow indicator in the chain, using whatever knowledge you have about the product and any indicators that came packaged with it.
It might also be an EA that’s slow. If so, it might be internally accessing a slow involved indicator. If you aren’t able to drill down to it, because the logs don’t give any hints, then we’ll need to leave it at that – the EA is the slowest link you’ve found in the chain.
Replace or fix the slow indicator
Once you’ve narrowed it down to an offending indicator, you should probably try to replace it. Find an alternative well-made indicator and adjust your trading strategy accordingly.
We don’t recommend trying to salvage the indicator, because this type of problem is often related to deeper design flaws like repainting – the problems could snowball.
On the other hand, if you’re the developer, you might be able to recover the situation. Here are some things to be conscientious about when designing the algorithm of an indicator:
- Check that the indicator is not re-writing the entire historical buffer every tick. If you agree with the non-repainting paradigm, then for most signaler and charting indicators, you should only write to historical buffers once.
- Look at any loop in your code, and check if it’s iterating over all bars on the chart. Or, if the number of iterations would grow larger and larger rather than stay constant. If so, help the loop to skip iterations by using cache variables to store reusable past loop values; and help the loop to break early; and try to remove the loop altogether by using indicator data buffers instead.
- Dynamic array-like data structures that you use to cache data over the entire lifetime of the program need to be regularly pruned and downsized, to clean away stale data.
The key takeaway in this section is to do a test run in the Strategy Tester for all involved indicators to identify the bottleneck. Then, fix or replace it. An indicator is the culprit 99% of the time, because in MT4/MT5 indicators run in the same processing queue (thread) as the user interface – which means any lag in any indicator will lag the user interface.
To be technically specific, the official MQL documentation suggests that indicators used inside EAs are run within the calling thread – which means that a lagging indicator run inside an EA will lag the EA, but not the user interface (thankfully). However, you should probably still try to replace it, since you wouldn’t want your EA to lag.
For a developer, be aware that an indicator’s OnCalculate
function is run once every tick, which could be several times a second. That’s why its algorithm should ideally be fast and of a constant running time complexity. Look into using additional indicator data buffers to cache values, if simpler data types aren’t enough.
2. Too many graphical objects on the chart
The second most common cause of a slow and lagging MT4/MT5 terminal is having too many graphical objects on charts. That is, over about 100,000 objects. You might not realize that you have too many, because it’s often hidden.
First of all, a graphical object refers to a special type of visual object you might see on a chart, like a rectangle, colored region, label, line or button. It’s anything listed in the Objects List for a chart.
To see the Objects List for a chart, right-click on the chart and select ‘Objects List’ from the menu.
If ‘Objects List’ doesn’t appear in the right-click menu, then there aren’t any graphical objects on that particular chart.
If your chart looks clean, there may still be objects on it far to the left in history, or the object might be invisible. So, the Objects List is the only definite way to know.
The Objects List includes things like lines you’ve placed on the chart manually using drawing tools.
If this list is too large, showing that any chart contains a huge number of objects (around 100,000 or even less), the entire MT4/MT5 application might begin to lag. This lag might happen even if no indicator or EA is running.
The exact number of objects required to start lagging your system might depend on your system specs.
Sometimes, having too many graphical objects on the chart is not the exact reason for lag, but it’s a tell-tale sign that the indicator or EA that generated the objects is constantly regenerating or refreshing all of them. For indicators and EAs, dealing with objects slows their operating speed significantly. You’ll notice this when you compare the speed of indicators and EAs in the Strategy Tester: the ones that generate graphical objects on the chart will run much slower.
If you’re a developer, you can improve the situation by programming a reasonable cleanup cycle for old graphical objects. You should also think about including a switch that turns off graphical objects for indicators that you want EAs to run internally.
If you’re a trader or user, you usually shouldn’t touch the Objects List. But sometimes in a dire situation, you need to delve in and clean up the mess – here’s how.
Step 1: Confirm that you have too many objects
To find out if you’re affected by this ‘too many objects’ problem, right-click on every chart you have open and select ‘Objects List’. If ‘Objects List’ isn’t on the menu, then there aren’t any objects on this chart, so it’s clean and the problem isn’t here – move on to check all open charts.
When the Objects List opens, be sure to toggle on ‘List all’ to reveal hidden items. The total number of objects is in the title bar. If this total is huge, in the tens of thousands, then having too many objects might be your problem.
In particular, look out for charts that run an indicator or EA and obviously contains colored regions, boxes, text, labels, buttons, trend lines, vertical or horizontal lines, and other pretty visual graphics.
If a chart looks clean, you still need to check it, because objects could be hidden in history. Even if you’re not running any indicator or EA, you might be accidentally restoring junk objects using the default template – we’ll explain this in the next part – so check the Objects List anyway.
After finding out that you have a huge number of objects being drawn on a particular chart, close that chart to confirm that the MT4/MT5 platform would run smoothly again after the objects are deleted. If you don’t want to close the chart, perhaps because you’re running a live trading EA on it, then you can still move ahead past this point to try to clean things up while things are running (at your own risk).
Step 2: Confirm what’s generating the objects
After you discover too many objects on your charts, the next step is to identify what’s doing it. That is, identify the indicator or EA that’s generating these objects on your chart in the first place.
It’s important to identify, because if you run it again, it’ll do it again – then you’ll need to clean up again!
Indicators or EAs that generate objects are usually obvious to identify – they draw boxes, regions, text, lines and labels on the chart. Using objects to achieve their visual goals is sometimes necessary and there’s no other way. However, a lot of the time these products don’t have a cleanup cycle. So, they accumulate objects and eventually freeze your system.
From here, another thing might happen to add to your list of problems: You might save a template while the indicator or EA is running, while lots of objects are on the chart. When you save a template, it saves all the objects it sees, and restores them whenever you load the template – this is an MT4/MT5 quirk. So, now, you might have a second hidden problem: you’re accidentally loading up a template that restores thousands of objects.
To find out if a template is doing this, check the Objects List before and after loading a template. It’s more obvious if there are no indicators or EAs running – then it must be the template doing it. To be absolutely certain, you can check template files (*.tpl files) in a text editor – if you find thousands of the keyword <object>
written in the file, then it’s a problem. Be sure to check ‘default.tpl’ as well – this is the default template that automatically loads on all charts by default.
So, when you identify what’s generating the objects, it’ll be an indicator or EA, and maybe also a template.
Step 3: Fix or replace what’s generating the objects
After you know what’s generating the objects, you should decide if you can fix it, or find a nicer replacement (for example, a similar indicator that doesn’t use graphical objects, but standard buffers instead).
If you’re a trader using an indicator or EA, and it’s generating objects without limit, then you’ll need to constantly delete old objects. It depends on whether you need to leave it on the chart long-term for live trading, and how long it takes for the product to accumulate too many objects.
If you really like the product and want to keep using it, you’ll need to do a cleanup regularly.
If you’ve found a template that accidentally restores thousands of objects, then save a clean new template: load the offending template, perform a cleanup, then re-save the template.
If you’re a developer, keep in mind that creating graphical objects in MT4 or MT5 is generally a slow operation. When creating user-friendly or mission-critical products, think about implementing a pruning or cleanup cycle. For indicators, include a switch to turn off creating objects, and redesign it to use standard buffers instead.
Step 4: Clean up
After you’ve identified the indicator, EA or template that generates too many objects, now you still need to manually clean up the mess so that MT4 or MT5 can run smoothly again.
To delete all objects manually, right-click on the chart and open the Objects List. Toggle on ‘List all’ to reveal hidden objects. Then select any single item and type ‘Ctrl-A’ to select all, then click Delete.
However, you should only do this once any running indicator or EA is removed and all your trading is safely stopped.
3. Making a slow system call too often
A rarer reason why MT4 or MT5 runs slowly, lags or freezes is because a custom indicator or EA makes a slow system call too often.
The term slow system call refers to certain special types of operations in programs. These operations are classified as slow because the operating system needs to get deeply involved.
2 common examples
Here are 2 common examples:
- Writing a file
- Making a web request
Writing a file is a slow type of operating system task. Writing too often can lock up not only the MT4/MT5 application, but sometimes your computer system as well. That’s why professional software will usually cache lines first, then flush everything to file in bulk later. It’s something to reconsider if you’re writing an EA that’s meant to write to a file several times per second.
In some software ecosystems it might be fine to make slow system calls often. However, in MT4 and MT5, especially in indicators, it’s usually not a good idea.
Web requests are another slow type of operation. Making a web request from an indicator isn’t usually allowed using MT4/MT5 standard provisions, but developers can bypass this advice by using a DLL. The problem with this is that indicators share the same processing queue (thread) as the user interface – so, if an indicator is stuck on trying to download something, the user interface will be stuck too.
What to look out for
If you’re a trader or user, look out for an indicator that is said to work with files or the internet. Indicators weren’t originally designed for these purposes, so check carefully to make sure it’s been made well, in a way that doesn’t block the system.
If you’re a developer, you’ll need to make wise design choices. Part of domain expertise is knowing the constraints of the ecosystem. So, if a producer requests features within an indicator that isn’t feasible because of technical boundaries, then by all means, let them know. The last thing you want to do is agree to creating file-writing indicator, then deliver a thing that freezes the entire system whenever it’s run.
Some things can be programmed but shouldn’t. Slow system calls are like heavy operations that can’t be simplified any further, so sometimes we have to adjust product design goals in favor of ensuring users have a smooth experience.
Summary
We’ve covered 3 common reasons for a slow, lagging or freezing MT4 or MT5 application. This article explained each reason at its core, and how to find and fix each one.
If you’re a trader using products you’ve found on the market, it boils down to 2 fixes: how to identify a slow indicator, EA or template, and how to clean up a hidden mess of objects.
If you’re a developer, it boils down to handling MT4/MT5 quirks and writing performant code.
Final mention: memory leaks and storage bloat
One final mention that we haven’t yet touched on is memory leaks. Technically, this is not the exact reason for slowness or lag, thanks to garbage collection in MT4 and MT5.
An actual memory leak is where a program loses track of all references to a memory location, so even though it wants to free up RAM, it can’t anymore. This kind of issue is possible, but is rare in code seen in this niche.
More commonly, the exact cause is storage bloat, where a storage variable in code accumulates more and more temporary data, but old unused data is never deleted. So, by design, the program eventually fills up all of RAM, and the computer starts to thrash.
If you’re a developer, this is something to be conscientious about: to regularly prune and downsize any dynamic arrays used for caching, in some kind of cleanup cycle.
Keeping a good program structure is essential.