Discussing the article: "Implementing Session Volume Profile in MQL5"

New comment

Check out the new article: Implementing Session Volume Profile in MQL5.

Build a responsive session volume profile indicator in MQL5 from tick data with draggable session bounds and dual anchoring. The article details hash-based bucket aggregation for historical and live ticks, a timer-driven rendering loop with partial updates, automatic or custom bucket sizing, pixel-anchored proportional bars, POC highlighting, and multi‑instance safety—so you can implement, optimize, and run multiple profiles on one chart without UI lag.

A session volume profile is the aggregation of volume by price level within a specific trading session chosen by the user. Traders use it to spot regions of high-volume activity, gauge support and resistance, judge whether a price range is fair, and find the Point of Control (POC).

Session Volume Profile

Unlike market profile (TPO) charts, which rely on OHLC bars to measure time at price, a volume profile is built from tick-level data. It therefore requires an efficient architecture to remain responsive and avoid unnecessary overhead. In this article we will develop a session volume profile indicator for tick-volume data with the following core features:

In the following sections, we will walk through the underlying data structures, inputs, event handlers, and rendering and updating functions required to build this indicator in MQL5. Let us begin with an overview of the indicator architecture.

A naive implementation would be recalculating the volume profile from historical tick data and rendering it on every incoming tick inside OnCalculate. This implementation has the advantage of being stateless; however, in active trading environments, the high frequency of incoming ticks will inevitably introduce severe chart latency due to the computations. We can improve this by maintaining the historical state of the volume profile and incrementally updating only the changes in OnCalculate. To optimize rendering performance, we will implement a timer-driven visual rendering system in OnTimer at a user-defined refresh interval. This decouples the rendering and update logic and keeps OnCalculate lightweight.

The OnTimer loop categorizes the tasks into three distinct update states:

Author: Prasad Fidelis Dsa

New comment