Diskussion zum Artikel "Erweiterte Speicherverwaltung und Optimierungstechniken in MQL5"
Der Artikel sieht sehr fragwürdig aus (nur ein paar Punkte).
Was ist die Klasse, die Sie hier erwähnt haben?
// Klassenvariable - created once double prices[]; void OnTick() { // Wiederverwendung des vorhandenen Arrays for(int i = 0; i < 1000; i++) { prices[i] = iClose(_Symbol, PERIOD_M1, i); } // Verarbeiten Sie die Daten... }
Das Vorhandensein des OnTick-Handlers und die Art und Weise, wie auf das Array zugegriffen wird, deutet darauf hin, dass Sie das Preis-Array in den globalen Bereich eingefügt haben, was eine schlechte Idee ist (wegen der Namespace-Verschmutzung, wenn das Array nur im Bereich des Handlers benötigt wird). Wahrscheinlich wäre es angemessener, den ursprünglichen Code aus dem gleichen Beispiel beizubehalten, aber das Array statisch zu machen, so dass jeder den Unterschied klar erkennen kann:
// Effizienter Ansatz (weist das Array einmal zu, kann seine Größe bei Bedarf anpassen) void OnTick() { // Dies bedeutet NICHT create (nor allocate) array on every tick static double prices[]; ArrayResize(prices, 1000); // Füllen des Arrays mit Preisdaten for(int i = 0; i < 1000; i++) { prices[i] = iClose(_Symbol, PERIOD_M1, i); } // Verarbeiten Sie die Daten... }
Auch wenn Sie Array of Structures (AoS) mit Structure of Arrays (SoA) für OHLCV ersetzen - der Zugriff auf die Preise der gleichen Bar braucht mehr Referenzen (Umschalten zwischen Arrays statt Inkrementierung Offset innerhalb einer einzigen Struktur) und verlangsamt den Prozess, aber solche Operationen sind sehr häufig.
Für dieses Beispiel mit OHLCV wäre es aus Gründen der Speicher- und Zeiteffizienz wahrscheinlich interessanter, alle Werte in ein einziges 2D- oder sogar 1D-Array zu packen:
double TOHLCV[][6];
Dies ist möglich, weil alle Werte der Typen (double, datetime, long) die gleiche Größe von 8 Byte haben und direkt ineinander gecastet werden können.
Für dieses Beispiel mit OHLCV wäre es aus Gründen der Speicher- und Zeiteffizienz wahrscheinlich interessanter, alle Werte in ein einziges 2D- oder sogar 1D-Array zu packen:
Ein 2D-Array anstelle eines Arrays von Strukturen spart vielleicht ein wenig Prozessorzeit, aber es erhöht den Zeitaufwand des Entwicklers für die Entwicklung und Pflege des Codes erheblich. Meiner persönlichen Meinung nach stimme ich mit dem Rest Ihrer Aussagen überein.
https://www.mql5.com/de/articles/17693#sec2
Schauen wir uns ein problematisches Beispiel an:
// Ineffizienter Ansatz - erstellt bei jedem Tick neue Arrays void OnTick() { // Dadurch wird bei jedem Tick ein neues Array erstellt double prices[]; ArrayResize(prices, 1000); // Füllen des Arrays mit Preisdaten for(int i = 0; i < 1000; i++) { prices[i] = iClose(_Symbol, PERIOD_M1, i); } // Verarbeiten Sie die Daten... // Array wird irgendwann zu Müll verarbeitet, aber das // erzeugt unnötigen Speicherplatzmangel }
Ein effizienterer Ansatz wäre:
// Klassenvariable - einmal erstellt double prices[]; void OnTick() { // Wiederverwendung des vorhandenen Arrays for(int i = 0; i < 1000; i++) { prices[i] = iClose(_Symbol, PERIOD_M1, i); } // Verarbeiten Sie die Daten... }
Der Artikel sieht sehr fragwürdig aus (nur ein paar Punkte).
Was ist die Klasse, die Sie hier erwähnt haben?
Das Vorhandensein des OnTick-Handlers und die Art und Weise, wie auf das Array zugegriffen wird, deutet darauf hin, dass Sie das Preis-Array in den globalen Bereich eingefügt haben, was eine schlechte Idee ist (wegen der Namespace-Verschmutzung, wenn das Array nur im Bereich des Handlers benötigt wird). Wahrscheinlich wäre es angemessener, den ursprünglichen Code des gleichen Beispiels beizubehalten, aber das Array statisch zu machen, so dass jeder den Unterschied klar erkennen kann:
Soweit ich es verstanden habe, handelt es sich bei dem Beispiel (das ich oben zitiert habe) grob gesagt um Pseudocode, d.h. der Autor achtet nicht auf das Folgende (um sich auf das zu konzentrieren, wovon er genau spricht, nehme ich an):
- Nach der Schleifenbedingung zu urteilen, ist die Größe des Arrays zur Kompilierzeit bekannt, aber dennoch ist das Array dynamisch.
- Obwohl das Array dynamisch ist, wurde ArrayResize in dem Code, der den effizienten Ansatz demonstriert, nicht aufgerufen.
- Im Hinblick auf die Effizienz wäre es vermutlich besser, die gesamte folgende Schleife durch einen einzigen CopySeries-Aufruf zu ersetzen:
// Wiederverwendung des vorhandenen Arrays for(int i = 0; i < 1000; i++) { prices[i] = iClose(_Symbol, PERIOD_M1, i); }
Im Hinblick auf die Effizienz, ich vermute, es wäre besser, die gesamte folgende Schleife mit einem einzigen CopySeries Aufruf zu ersetzen:
Korrigieren Sie mich, wenn ich falsch liege, aber soweit ich mich erinnere, enthält jeder iClose-Aufruf einen CopySeries-Aufruf unter der Haube.
Der vorliegende Artikel enthält aufschlussreiche und zum Nachdenken anregende Inhalte, die zur Diskussion anregen.
Die technische Darstellung ist klar und gut erklärt, so dass der Leser ihr leicht folgen und sich mit ihr beschäftigen kann.
Ich danke Ihnen vielmals.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Erweiterte Speicherverwaltung und Optimierungstechniken in MQL5 :
MQL5 ist unbestreitbar leistungsstark, aber mit dieser Leistung geht auch Verantwortung einher - vor allem, wenn es um den Speicher geht. Viele Entwickler konzentrieren sich ausschließlich auf Strategielogik, Einstiegspunkte und Risikomanagement, während die Speicherverwaltung im Hintergrund zu einer tickenden Zeitbombe wird. Bei der Skalierung Ihres Codes - Verarbeitung von mehr Symbolen, höheren Frequenzen und umfangreicheren Datensätzen - kann die Vernachlässigung des Speichers zu Leistungsengpässen, Instabilität und verpassten Chancen führen.
In diesem Artikel gehen wir unter die Haube. Wir werden untersuchen, wie der Speicher in MQL5 wirklich funktioniert, die häufigsten Fallen, die Ihre Systeme verlangsamen oder zum Ausfall führen, und - was am wichtigsten ist - wie man sie beheben kann. Sie lernen praktische Optimierungstechniken kennen, die Ihre Handelsprogramme schneller, schlanker und zuverlässiger machen.
Hier ist eine effiziente Speichernutzung besonders wichtig:
Hochfrequenzhandel: Jede Millisekunde ist ein potenzieller Vorteil - oder ein potenzieller Verlust.
Multi-Timeframe-Analyse: Kombinierte Charts? Erwarten Sie, dass sich der Speicherdruck vervielfachen wird.
Schwere Indikatorlogik: Komplexe mathematische Berechnungen und große Datensätze können alles zum Stillstand bringen, wenn sie nicht verwaltet werden.
Backtests mit großen Kurshistorien: Ohne intelligente Optimierung können sich Backtests anfühlen, als würde man Farbe beim Trocknen zusehen.
Wenn Sie bereit sind, sich ernsthaft mit der Leistung auseinanderzusetzen, lassen Sie uns eintauchen - und Ihre MQL5-Systeme so effizient wie intelligent machen.
Autor: Sahil Bagdi