Anatomy of a High-Performance EA (Part I): O(1) Bitwise Architecture and ID Packing in Trade Assistant Pro

Dana64 — Fri, 13 Nov 2026 04:00:51 +0000

When a developer begins programming in MQL5, naming chart objects with text strings seems like the most intuitive approach. If you need to draw a Take Profit button for ticket 482910, you simply concatenate "Panel_TP_" + IntegerToString(482910) and, when the user clicks in OnChartEvent(), you use StringFind() or StringSplit() to figure out which trade needs to be modified.

In a small panel with five buttons, this approach works without any apparent issues. However, when scaling up to a full-featured institutional trade manager like Trade Assistant Pro (TAP)—capable of managing multiple simultaneous orders, dynamic Grid levels, Trailing Stops, Break Even, virtual orders, and floating CCanvas windows at 120 FPS—constant string manipulation becomes a silent bottleneck. Every string concatenation or split triggers dynamic memory allocations (heap allocations) that fragment resources and cause latency spikes right when market volatility demands an instantaneous response.

In this article, we will examine the actual architecture that solves this problem inside the TAP source code. You will see how to replace slow text parsing with a system of Bitwise OpCodes packed into 64-bit integers, how to leverage contiguous range arithmetic to achieve O(1) routing, and what the real-world technical limits and trade-offs of this design are.

The Invisible Bottleneck of Text Strings (`string`)

To understand the scale of the problem, look at what happens during an active MetaTrader 5 session. Suppose you hold ten open positions and each one displays its control row, Grid levels (up to 5 TP levels and 5 SL levels), Break Even levels, Trailing Stop lines, and action buttons. That easily exceeds 200 active graphical objects simultaneously.

Every time you move the mouse (CHARTEVENT_MOUSE_MOVE) or pan the chart (CHARTEVENT_CHART_CHANGE), the EA engine must identify which object sits beneath the cursor or update its screen coordinates. If the system relies on text-based names:

Parsing and fragmentation overhead: Functions like StringSplit() or StringSubstr() force the CPU to iterate character by character and allocate temporary memory for new strings on every single millisecond of the event.
Comparison cascades: A block with dozens of else if(sparam == "btn_...") statements forces the processor to compare strings sequentially in linear O(N) complexity until a match is found.
Noise from external objects: If the user has manually drawn a Fibonacci retracement or trendlines on the same chart, the text parser has to inspect and discard all of those names manually.

The engineering solution implemented in TAP starts from a strict premise: the CPU should never read text to understand which button you pressed. Text should only exist as a visual interface for the human and to satisfy the final requirement of the MetaTrader API; internally, everything must be binary math.

64-Bit Bitwise Packing: Ticket and OpCode in a Single `ulong`

The core of this system lies in a centralized numeric dictionary (ENUM_OPCODE) combined with three bitwise operations. In MQL5, both real broker tickets and internal virtual tickets are 64-bit unsigned integers (ulong). Instead of storing the ticket number and the button type as two strings separated by an underscore, TAP fuses them into a single 64-bit integer.

Let us see how this is implemented directly in the EA's code:

//--- Centralized OpCode Dictionary (Unique numeric identifiers)
enum ENUM_OPCODE
  {
   OP_NONE = 0,

   //--- Main Manager Elements (EA2)
   OP_TM_ENTRY         = 200,
   OP_TM_MOVE          = 201,
   OP_TM_MENU          = 202,
   OP_TM_TP            = 204,
   OP_TM_SL            = 205,

   //--- Contiguous ranges for Grid & Color Matrix
   OP_HLINE_GRID_TP_1  = 401, // 401..405
   OP_HLINE_GRID_SL_1  = 411, // 411..415
   OP_TM_COLOR_0       = 350, // 350..359

   //--- Highest assigned OpCode in the current architecture
   OP_TM_INP_EDIT_TRIG = 3307
  };

//+------------------------------------------------------------------+
//| Bitwise Packing: Combines 52-bit Ticket + 12-bit OpCode          |
//+------------------------------------------------------------------+
ulong PackID(ulong ticket, int opcode)
  {
   //--- Shift ticket 12 bits left and attach the OpCode in the lower bits
   return (ticket << 12) | (opcode & 0xFFF);
  }

//+------------------------------------------------------------------+
//| Creates an MT5-compatible numeric object name                    |
//+------------------------------------------------------------------+
string MakeTMName(ulong ticket, int opcode)
  {
   ulong id = (ticket << 12) | (opcode & 0xFFF);
   return IntegerToString(id);
  }

//+------------------------------------------------------------------+
//| Ultra-fast Parser: Extracts Ticket and OpCode in O(1)            |
//+------------------------------------------------------------------+
ushort ParseTMObject(const string objName, ulong &outTicket)
  {
   outTicket = 0;

   //--- Native objects like "Fibo 123" immediately evaluate to 0
   ulong id = StringToInteger(objName);
   if(id == 0)
      return OP_NONE;

   //--- Bitwise unpacking in a single CPU register cycle
   outTicket = id >> 12;        // Recover original ticket
   return (ushort)(id & 0xFFF); // Mask out the lower 12 bits (OpCode)
  }

Let us pause to examine the engineering behind this packing scheme, because every constant was chosen with a specific mathematical purpose:

The anatomy of the 64 bits: The 0xFFF bitmask equals twelve ones in binary (1111 1111 1111), reserving exactly 12 bits for the OpCode. This provides a range from 0 to 4,095 distinct identifiers per trade. Since the highest OpCode in the system (OP_TM_INP_EDIT_TRIG) is 3307, there is comfortable headroom without encroaching on the upper bits.
Plenty of room for real and virtual tickets: The remaining 52 bits are dedicated to the ticket ($2^{52} - 1 \approx 4.5 \times 10^{15}$). This accommodates both real tickets from any broker and the EA's own virtual orders—whose base starts at VIRTUAL_TICKET_BASE = 1000000000000ULL ($10^{12}$)—without any risk of overflow.
Instant filtering of unrelated objects: Look at the line ulong id = StringToInteger(objName);. If the user manually draws a line named "Bullish Trend" or "Fibo 1", MQL5's native function detects that the first character is not a digit and returns 0 immediately. With a single check (if(id == 0) return OP_NONE;), the engine discards all visual chart clutter without executing a single StringFind().

O(1) Routing via Numeric Ranges and the Suffix Trick

Once every CUIEngine button and chart object responds to numeric integers rather than strings, the event-dispatching code changes dramatically. In the CUIButton class, the old text identifier disappears in favor of int m_id;.

This unlocks two powerful optimizations in interaction handling: contiguous range arithmetic and natural suffix truncation.

Let us see both patterns working together in TAP's click handler and advanced line-drag detector:

//+------------------------------------------------------------------+
//| O(1) Arithmetic Dispatch inside ProcessCanvasClick               |
//+------------------------------------------------------------------+
//--- Grid TP Toggle (Opcodes 51 to 55)
if(id >= OP_GRID_TP_1 && id <= OP_GRID_TP_5)
  {
   int row = id - OP_GRID_TP_1; // Direct index calculation (0..4)
   TemplateState.grid.rows[row].isActiveTP ^= true;
   BuildCanvasUI();
   UpdateInputsFromLines();
  }

//--- Color Picker Palette inside ProcessOrderMenuClick (350 to 359)
if(opcode >= OP_TM_COLOR_0 && opcode <= OP_TM_COLOR_9)
  {
   int colorIdx = opcode - OP_TM_COLOR_0; // Direct index (0..9)
   color pal[10] = { C'0,120,215', C'40,167,69', C'220,53,69', C'255,160,0',
                     C'180,80,255', C'0,240,240', C'255,20,110', C'255,200,0',
                     C'150,150,150', clrNONE };
   mem.customColor = pal[colorIdx];
   SaveTradesToBin();
  }

//+------------------------------------------------------------------+
//| Universal Parser: Ignores visual suffixes ("_Btn", "_Line")      |
//+------------------------------------------------------------------+
int DetectLineDrag(string objName, ulong &outTicket, int &outRow, string &outHLineName)
  {
   //--- StringToInteger stops parsing at '_', stripping suffixes automatically
   ushort opcode = ParseTMObject(objName, outTicket);
   if(opcode == OP_NONE)
      return 0;

   //--- Reconstruct pure numeric HLine name in one bitwise operation
   outHLineName = IntegerToString((outTicket << 12) | (opcode & 0xFFF));

   if(opcode >= OP_HLINE_GRID_TP_1 && opcode <= OP_HLINE_GRID_TP_5)
     {
      outRow = opcode - OP_HLINE_GRID_TP_1 + 1;
      return 10; // Drag type: Grid TP
     }
   if(opcode >= OP_HLINE_GRID_SL_1 && opcode <= OP_HLINE_GRID_SL_5)
     {
      outRow = opcode - OP_HLINE_GRID_SL_1 + 1;
      return 20; // Drag type: Grid SL
     }
   if(opcode == OP_HLINE_BE_START) { outRow = 0; return 30; }
   if(opcode == OP_HLINE_TS_START) { outRow = 0; return 40; }

   return 0;
  }

Notice two key details in these snippets:

Goodbye to lookup tables and loops: When you click Grid level 4 or the seventh color in the palette, there is no ten-case switch statement and no for loop searching for which row matches the button. A simple integer subtraction (opcode - OP_TM_COLOR_0) yields the exact array index in a single clock cycle.
The suffix trick in DetectLineDrag: Each visual level for the Grid, Break Even, or Trailing Stop consists of three objects: an invisible horizontal line (4096401), a dotted pixel line (4096401_Line), and a text label (4096401_Btn). When you grab the label with the mouse, StringToInteger("4096401_Btn") reads up to the first non-numeric character (_) and returns exactly 4096401. In this way, ParseTMObject ignores the _Btn and _Line suffixes automatically without calling StringReplace(), and reconstructs the true line name on the very next line.

The same principle applies to DeleteAllTradeVisuals(ulong ticket), where completely cleaning up a panel and its up to 14 advanced lines is reduced to iterating over a small array of integer OpCodes and passing them through MakeTMName(), eliminating the danger of deleting unrelated objects through partial substring matches.

Zero Memory Allocations in Critical Loops: The `CTradeState` Cache

Even though MakeTMName() is remarkably fast, there is a physical constraint imposed by the MetaTrader 5 API: functions like ObjectSetInteger() and ObjectSetString() require the object name to be passed as a string. That means if we call MakeTMName() inside OnTimer() or inside the 120 FPS vertical panning engine (TM_UpdatePanVisualsFast), we would still be executing IntegerToString() hundreds of times per second.

To drive real-time memory allocations literally down to zero, the CTradeState class—which represents the RAM state of every live or virtual trade—precomputes all of its Bitwise names once in its constructor:

class CTradeState
  {
public:
   ulong             ticket;
   //--- Pre-computed Bitwise Name Cache (Zero String Allocation in Loops)
   string            obj_btnEntry;
   string            obj_btnMove;
   string            obj_btnMenu;
   string            obj_btnTP;
   string            obj_btnCancToggle;
   string            obj_rectTP;
   string            obj_hlineTP;
   string            obj_btnSL;
   string            obj_rectSL;
   string            obj_hlineSL;
   string            obj_btnSec;
   string            obj_visSec;
   string            obj_btnCanc;
   string            obj_visCanc;

   CTradeState(ulong t, string sym)
     {
      ticket = t;
      //--- Computed only once when the trade enters RAM
      if(ticket > 0)
        {
         obj_btnEntry      = MakeTMName(ticket, OP_TM_ENTRY);
         obj_btnMove       = MakeTMName(ticket, OP_TM_MOVE);
         obj_btnCancToggle = MakeTMName(ticket, OP_TM_CANCEL_TOGGLE);
         obj_btnMenu       = MakeTMName(ticket, OP_TM_MENU);
         obj_btnTP         = MakeTMName(ticket, OP_TM_TP);
         obj_rectTP        = MakeTMName(ticket, OP_TM_RECT_TP);
         obj_hlineTP       = MakeTMName(ticket, OP_HLINE_TP);
         obj_btnSL         = MakeTMName(ticket, OP_TM_SL);
         obj_rectSL        = MakeTMName(ticket, OP_TM_RECT_SL);
         obj_hlineSL       = MakeTMName(ticket, OP_HLINE_SL);
         obj_btnSec        = MakeTMName(ticket, OP_TM_SEC);
         obj_visSec        = obj_btnSec + "_VisLine";
         obj_btnCanc       = MakeTMName(ticket, OP_TM_CANCEL_LBL);
         obj_visCanc       = obj_btnCanc + "_VisLine";
        }
     }
  };

Thanks to this RAM cache, when the user pans the chart with the mouse wheel or when UpdateLiveStats() refreshes floating P/L every second, the code reads mem.obj_btnEntry or mem.obj_rectTP directly without concatenating or converting a single integer. The gain in responsiveness is immediate, especially when multiple open panels coexist on the same symbol.

Technical Debate: Design Limits and Migration Debt

No architecture is free of trade-offs. When auditing this approach inside TAP, three critical points emerge that every developer should evaluate before implementing it in their own projects:

The 12-bit ceiling (4,095): Reserving 12 bits for the OpCode comfortably covers the current 3,307 codes, but it imposes a strict upper bound. If future versions add more than 788 new unique controls, the 0xFFF mask would cause silent collisions (wrap-around). Expanding it to 13 or 14 bits is trivial (0x3FFF), but requires verifying that the ticket << 14 shift still leaves enough room for long institutional broker tickets.
Numeric false positives on user objects: The StringToInteger(objName) == 0 filter assumes that objects created manually by the trader do not start with digits. If a user creates a line named "2026_Support", ParseTMObject() will extract 2026 as a composite ID. For this reason, a second validation layer is essential—such as verifying that the extracted ticket exists in TradeRAM or that the OpCode falls within a valid switch range—just as TAP's router does.
Hybrid architecture in transition: An honest review of the codebase shows that while the core buttons and lines already operate 100% under Bitwise identifiers, auxiliary modules with legacy string prefixes still coexist alongside them (for example, "TM_Exp_Arrow_" on expiration arrows or "GhostInput_EA2_" on certain edit boxes). In large systems built iteratively, this coexistence is normal and pragmatic: you optimize the 120 FPS critical path first (mouse movement, panning, and ticks) and leave sporadic events for later refactoring phases.

Conclusion

Replacing conventional string handling with Bitwise packing completely transforms how a complex interface behaves in MetaTrader 5. By compressing the trade's identity and the control's function into a single 64-bit integer, the system stops spending CPU cycles reading text and operates instead through bit shifts and register-level arithmetic.

Practical results in Trade Assistant Pro:

O(1) unpacking: A single call to ParseTMObject() separates ticket and OpCode, filters out native chart objects, and ignores visual suffixes.
String-free dispatching: Contiguous ranges in ENUM_OPCODE resolve Grid rows, color palettes, and dynamic parameters through simple subtraction.
Zero hot-path allocations: The precomputed cache inside CTradeState avoids calling IntegerToString() during visual update loops and live statistics refreshes.

In upcoming analyses, we will dive into the next pillar sustaining TAP's fluidity: its Asynchronous Execution Engine, where we will see how to combine OrderSendAsync, a strict Rate Limiter to comply with Prop Firm rules, and an Optimistic UI architecture with automatic Rollback upon broker rejections. Would you like us to explore the asynchronous engine in the next installment, or would you prefer to examine the multi-canvas window manager (CWindowManager) first?

You can explore the full source code and repository for Trade Assistant Pro on GitHub: https://github.com/Tigraso/MQL5-Advanced-Trading-System

DEV Community: Dana64