Discussing the article: "Custom Debugging and Profiling Tools for MQL5 Development (Part III): Regression Gates for Performance and Trading Rules"

New comment
 

Check out the new article: Custom Debugging and Profiling Tools for MQL5 Development (Part III): Regression Gates for Performance and Trading Rules.

This article adds a regression gate to the MQL5 debugging and profiling workflow. It keeps the Part II profiler, TestLite runner, and trading math helper as contracts, then compares current profiler evidence with an accepted baseline. The workflow also adds symbol-aware assertions, compact status files, and report tables so performance drift, missing tests, and broker-assumption problems are visible before a build is accepted.

Part II produced two useful artifacts: a profiler CSV and a deterministic unit-test report. That already moves the project beyond a quiet Experts tab, but a single report still describes only one run. Part III adds the missing decision layer while preserving the Part II contracts: the profiler writes the same CSV, the unit-test runner writes the same TestLite report, and the trading math helper remains the owner of the pure functions. The regression gate compares the current evidence with an accepted baseline and turns that comparison into a decision.

The practical problem is familiar: an Expert Advisor can compile and the Strategy Tester can finish, while a regression remains hidden behind a harmless-looking log. Typical examples are listed below.

  • A buffer-copy path becomes more expensive after an indicator change.
  • A section that used to run on new bars starts running on every tick.
  • A lot-size rule passes on EURUSD but fails on a symbol with a different volume step.
  • A signal accidentally reads the current forming bar after a refactor.

The gate answers three practical questions.

  • Did the selected profiled sections move enough to deserve PASS, WARN, SKIP, or FAIL?
  • Do the pure trading-math tests from Part II continue to pass?
  • Do the symbol-specific assumptions used by the example EA remain valid?

This is not a replacement for MetaEditor profiling. MetaEditor already has a built-in profiler that can collect execution statistics for functions and code lines, and it can run on a chart or with historical data in the Strategy Tester. That tool remains the right choice for broad discovery. The embedded gate solves the next maintenance problem: after the relevant sections are known, did those sections materially regress compared with a trusted baseline? The output is intentionally plain: status, delta, and failure files, plus trade-assertion and symbol-assumption reports. The workflow stays simple: run unit tests, run the profiled EA, promote a clean profile to a baseline, and compare the current run against it before that run becomes the new reference point.

Author: Sahil Bagdi

New comment