mirror of
https://github.com/A6-9V/MQL5-Google-Onedrive.git
synced 2026-04-11 14:30:57 +00:00
9d866ce9f7
This commit implements several performance optimizations in the SMC_TrendBreakout_MTF_EA.mq5: 1. **Early Exit:** Moved the `PositionSelect` check to the beginning of the `OnTick` handler (after the new bar check). This avoids expensive market data fetching (`CopyRates`, `CopyBuffer`) and signal calculations if a position is already open. 2. **Reduced Data Fetching:** Reduced the fetch count in `CopyRates` and `CopyBuffer` (Donchian/EMA) from 3 to 2, as only the current and previous bars are used in the logic. 3. **Lazy Price Fetching:** Replaced the undefined/redundant `Ask` and `Bid` variables with efficient price retrieval using `SymbolInfoTick` only when a signal is confirmed. 4. **Optimized Array Management:** Refactored occasionally-used indicator buffers (EMA, ATR) into fixed-size local arrays to avoid dynamic allocation overhead and potential shadowing issues identified during code review. These changes measurably reduce the terminal overhead on every new bar and ensure better resource utilization during live trading. Co-authored-by: Mouy-leng <199350297+Mouy-leng@users.noreply.github.com>
28 lines
3.4 KiB
Markdown
28 lines
3.4 KiB
Markdown
# Bolt's Journal ⚡
|
|
|
|
This journal is for CRITICAL, non-routine performance learnings ONLY.
|
|
|
|
- Codebase-specific bottlenecks
|
|
- Failed optimizations (and why)
|
|
- Surprising performance patterns
|
|
- Rejected changes with valuable lessons
|
|
|
|
## 2024-07-25 - MQL5 Native Functions vs. Scripted Loops
|
|
**Learning:** My assumption that a manual MQL5 loop over a pre-cached array would be faster than built-in functions like `iHighest()` and `iLowest()` was incorrect. The code review pointed out that MQL5's native, built-in functions are implemented in highly optimized C++ and are significantly faster than loops executed in the MQL5 scripting layer. The original comment stating this was correct.
|
|
**Action:** Always prefer using MQL5's built-in, native functions for calculations like finding highs/lows over manual loops, even if the data is already in a local array. The performance gain from the native implementation outweighs the overhead of the function call.
|
|
|
|
## 2024-07-26 - Native ArrayMaximum/ArrayMinimum Efficiency
|
|
**Learning:** Confirmed that native `ArrayMaximum()` and `ArrayMinimum()` are the preferred way to find extreme values in price arrays. Also, when using these functions, it's important to check if they return `-1` to avoid invalid array access, especially if the `count` or `start` parameters might be dynamic.
|
|
**Action:** When replacing manual loops with native array functions, always include a check for the `-1` return value to ensure robustness while gaining performance.
|
|
|
|
## 2026-01-19 - Native Object Cleanup in MQL5
|
|
**Learning:** While iterating through chart objects manually is flexible, it becomes a major bottleneck if the chart has thousands of objects. For simple prefix-based cleanup (often used in indicators), the native `ObjectsDeleteAll(0, prefix)` is significantly more efficient than a scripted loop calling `ObjectName()` and `StringFind()` for every object on the chart.
|
|
**Action:** Use `ObjectsDeleteAll()` for bulk object removal by prefix whenever the "keep N latest" logic is not strictly required or can be safely bypassed for performance.
|
|
|
|
## 2026-01-20 - Robust New Bar Check in MQL5 OnCalculate
|
|
**Learning:** An early exit in `OnCalculate` based on bar time MUST check `prev_calculated > 0`. If `prev_calculated == 0`, the terminal is requesting a full recalculation (e.g., after a history sync or data gap fill), and exiting early would result in stale data. Also, using `iTime()` is more robust than indexing into the `time[]` array if the array's series state is unknown.
|
|
**Action:** Always wrap "new bar" early exits in indicators with `if(prev_calculated > 0 && ...)` and prefer `iTime()` for the current bar's timestamp.
|
|
|
|
## 2026-01-21 - MQL5 Local Array Sizing and Shadowing
|
|
**Learning:** Declaring large or dynamic arrays as `static` in MQL5's `OnTick` is good for memory reuse. However, for small, occasional data (like confirmation EMAs or ATR), fixed-size local arrays (e.g., `double buffer[2]`) are safer and more efficient. They avoid the overhead of dynamic resizing by `CopyBuffer` and eliminate the risk of "shadowing" or "uninitialized state" bugs that can occur with static dynamic arrays if they are not consistently populated on every execution path.
|
|
**Action:** Use fixed-size local arrays for small data sets (1-5 elements) that are only needed conditionally. Reserve `static` dynamic arrays for large data (like price history) that is required on every tick.
|