Why Good EA Optimization Takes Time: RAW Data, Real Ticks and Computing Power
When testing an EA, data quality matters just as much as the code.
For execution-sensitive systems, especially XAUUSD scalpers, breakout strategies and EAs with relatively small targets, I do not consider Demo data a reliable basis for comparing results. I also prefer RAW/ECN/Prime environments over Standard accounts when the purpose is research and optimization.
Demo is useful for technical checks: whether the EA opens orders correctly, calculates lot size, recognizes the symbol and works without errors. But it is still a simulated environment. It cannot properly represent real slippage, liquidity and live execution.
Standard accounts add another variable because part of the broker's cost is usually built into the spread. For research, I prefer real tick history from a RAW-type environment where spread and commission can be analyzed separately.
Real tick data is large
Real tick history is very different from storing M1 or H1 candles.
Every Bid and Ask update matters. On an active instrument such as gold, several years of history can become a very large dataset.
For example, my PU Prime XAUUSD history from 2020 to 2026 occupies about 10 GB on disk.
That is one symbol from one broker.
This amount of data becomes important for systems using small Take Profit and Stop Loss levels, trailing stops, breakout logic, spread filters or fast entries. Two price movements may produce an almost identical M1 candle while having a completely different tick sequence inside that minute.
An OHLC backtest is much lighter and faster. It is also a much rougher model of what actually happened.
Optimization is computationally expensive
One backtest is easy.
Optimization is different.
The same strategy may need to be tested hundreds or thousands of times with different parameter combinations. A serious optimization can easily contain:
500, 1,000 or more passes.
Every pass may process several years of real XAUUSD ticks.
MetaTrader 5 distributes those passes between testing agents, often using many CPU cores in parallel. Historical data must be read, synchronized and cached while each agent repeatedly calculates indicators, signals, trades, stops, equity, drawdown and other statistics.
This creates significant load on the CPU, RAM and storage subsystem.
The data is not simply “a 10 GB file loaded once into memory”. MetaTrader works with history, caches and individual testing agents, but the practical result is the same: long real-tick optimizations are resource-intensive.
This is the same workflow I use when developing and maintaining my own EAs. A parameter change that looks trivial from the outside can require a completely new optimization cycle before I consider it verified.
Why I use long periods
A short optimization can produce excellent numbers very easily.
Three favourable months may show a smooth equity curve, high Profit Factor and low drawdown. The problem is that those three months may represent only one market regime.
I prefer testing across periods containing different conditions:
quiet markets, strong trends, high volatility, low volatility, major news and very different gold behaviour.
This is why a period such as 2020–2026 is much more informative than optimizing only the latest few months.
But quality has a cost.
A six-year real-tick test multiplied by 1,000 optimization passes is a substantial computing task.
Broker data also changes the result
There is no single universal XAUUSD feed.
Spot FX and metals are mainly OTC markets. Different brokers receive prices from different liquidity sources, so their tick histories can differ.
The same EA with exactly the same settings may therefore produce different results on different broker feeds.
Differences may come from:
spread, tick sequence, commission, contract specification, swap and eventually live slippage.
That is why I normally follow this sequence:
real RAW tick history → optimization → out-of-sample or forward validation → small live RAW test → execution analysis.
The Strategy Tester evaluates the historical logic. A small live account then shows what historical testing cannot reproduce perfectly: real spread behaviour, slippage, latency and execution.
Why some EA questions take time to answer
Sometimes a user asks a very simple question:
“Is this set better?”
“Should I change this parameter?”
“Why are my results different?”
The question may be short, but a reliable answer may require a new test.
That can mean several years of real tick history, hundreds or thousands of optimization passes, analysis of the strongest parameter areas and then validation on data that was not part of the optimization.
This is also why I occasionally cannot give users of my EAs a definitive answer immediately. If the question depends on optimization rather than a simple configuration issue, I prefer to run the research first instead of guessing.
A quick opinion can take five minutes.
A result supported by data can take considerably longer.
Fast testing and good testing are not the same thing
Fast testing modes are useful during development. They help reject bad ideas quickly.
But when a strategy reaches the final research stage, accuracy becomes more important than speed.
For that stage I want:
real ticks, a meaningful historical period, enough optimization passes and out-of-sample validation.
That requires disk space.
It requires RAM.
It requires CPU power.
And it requires time.
A 10 GB XAUUSD history combined with 1,000 optimization passes is not unusual when the objective is to understand how an EA behaves across several years of real market data.
There is a large difference between finding settings that look good and researching whether those settings are actually robust.
Good optimization is not the fastest optimization. It is optimization based on sufficiently good data, a meaningful test period and results that can survive outside the optimized sample.
