MT5 und Geschwindigkeit in Aktion - Seite 63
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Liebe Entwickler, könnten Sie mir bitte mitteilen, wie MQL_MEMORY_USED berechnet wird?
Ich habe eine Berechnung des Speichers durchgeführt, den alle EA-Variablen belegen.
Sie beträgt weniger als 10 %. Wenn ich es richtig verstehe, umfasst MQL_MEMORY_USED den History-Cache und den CopyTicks-Cache. Aber es ist immer noch viel weniger.
Gleichzeitig verbraucht der parallele Expert Advisor ein Vielfaches weniger. Aber das Prinzip ist das gleiche.
Was ist im Allgemeinen in diesem Wert enthalten?
Ich habe eine Vorlage mit Expert Advisor gespeichert und sie auf dasselbe Diagramm angewendet, indem ich ein Neuladen veranlasste. Ich habe es so gesehen.
Die Speichernutzung hat sich um fast eine Größenordnung verändert. Bislang ist es schwierig zu erklären, was das bedeutet.
Viele Programme haben einen kumulativen Effekt bei der Speichernutzung. Dies ist eine Sünde von Browsern und manchmal sogar von Word. Auch das Terminal kann daran schuld sein. Außerdem werden alle Protokolle standardmäßig geschrieben, und es kann leicht eine Woche dauern, wenn man zu viele Aktionen in einer Giga hat. Dies ist ein Übel, das bewältigt werden muss. Aber es ist nicht klar, wie.
Vielleicht wissen Sie, wie man programmatisch ein Finanzinstrument auswählt und nicht ewig hängen bleibt?
Durch einen Indikator
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
MT5 und Geschwindigkeit in Aktion
Renat Fatkhullin, 2020.10.14 04:15
Für das Massenticken ist mehr Speicher erforderlich.
4 GB (Preis 20 €) sind im Jahr 2020 für Analysen und Forschung nicht mehr von Nutzen.
Für Market Products ist dieser Ansatz nirgendwo gut. Wir müssen die 10-Sekunden-Speicherung von unnötigen Daten durch eine solche Krücke umgehen.
Ein triviales Marktprodukt in Form eines Market Screeners zu erstellen, ist für MT5 aufgrund des zu hohen Speicherverbrauchs eigentlich nicht machbar.
Ein triviales Marktprodukt in Form eines Market Screeners zu erstellen, ist für den MT5 aufgrund des hohen Speicherverbrauchs eigentlich nicht machbar.
Das Terminal verbraucht nach dem Start sehr viel Speicher.
Nach der Ausführung des Screeners begann er 2 Gigabyte zu verbrauchen (TERMINAL_MEMORY_USED und nahm mit der Zeit nicht ab). Dies ist mit nur einem offenen Chart für 5000 M1-Balken.
Ich habe keinen Screenshot gespeichert. Aber beschlossen, in einem Beispiel, das zeigt, Speicher essen Terminal nicht an sich, wo es nur dumm ist zu werfen.
Das Skript erstellt einfach Kopien der Originalsymbole aus dem Market Watch. Ich sollte alle Symbole in MQ-Demo hinzufügen und dieses Skript zuerst im kalten und dann im heißen Zustand ausführen.
Und nach dem Hot Run (wenn die Ticks bereits in Form von tkc-Dateien auf der SSD liegen) werde ich einen enormen Speicherverbrauch feststellen, wo er bei einer ordnungsgemäßen Implementierung nicht benötigt wird.
Beim Ausführen des Skripts habe ich jedoch festgestellt, dass es sich bei MQ-Demo aufhängt. Es kann nur durch Abnormales Beenden entladen werden, woraufhin das Terminal nicht mehr als 1 GB Speicher freigibt.
Es ist einfach, diesen Screenshot mit dem zu Beginn zu vergleichen.
Ich bin mir nicht sicher, ob dies ein Fehler oder eine Funktion ist. Ich habe selbst noch keine Antwort gefunden. Aber die Frage bezieht sich auf die Leistung, und ich denke, es ist besser, sie hier zu stellen.
Wenn wir zum Beispiel 22 Puffer des Typs DRAW_SECTION zu einem leeren Indikator hinzufügen, dann verzögert sich das Terminal beim Start eines solchen Indikators für ein Diagramm mit 1000000 Balken oder mehr erheblich (es verursacht eine beträchtliche CPU-Last) und verbraucht erhebliche Mengen an Speicher, selbst wenn der Indikator nichts berechnet.
Mein Interesse wurde durch die Tatsache geweckt, dass bei der Verwendung von Puffern mit anderen Typen alles problemlos funktioniert und eine solche Verlangsamung nicht zu beobachten ist.
Ich habe zum Beispiel den folgenden Code auf einem einzelnen Diagramm mit 1000000 Balken ausgeführt, und er verbrauchte etwa 500 MBytes und verzögert sich, insbesondere das Diagramm selbst.
Ändere ich jedoch den Puffertyp in, sagen wir, DRAW_LINE, wird die Belastung des Prozessors drastisch reduziert, Verzögerungen werden nicht beobachtet, und der Speicherverbrauch ist fünfmal geringer (etwa 100 MByte).
Ähnliche Tests wurden mit verschiedenen Builds durchgeführt, bis hin zu 2019er Builds, und die Situation ist die gleiche.
Ein einzelner Bürger zogein Duplikat einer unschätzbaren Ladung MQL-Code aus seiner weiten Hose hervor, das zeigte, dass die Krücke unter den gleichen Bedingungen schneller arbeitete als die reguläre Funktion.
Ein sehr einfacher Test:
20 Expert Advisors auf EURUSD, d.h. alle OnTick-Prozesse gleichzeitig. Die Bauart des Terminals ist 2664. Der Test läuft ohne Optimierung, Kompilierung und andere zusätzliche Belastung bei 100 % CPU - Sie werden doch nicht einen echten "hft"-Handel auf diesem Hintergrund durchführen, oder?
Typisches Testprotokoll:
Ein sehr einfacher Test:
20 EAs auf EURUSD, d.h. alle OnTick-Prozesse zur gleichen Zeit. Terminal-Build 2664. Der Test läuft ohne Optimierung, Kompilierung und andere zusätzliche Arbeitsbelastung auf 100% CPU - Sie werden doch nicht einen echten "hft"-Handel auf diesem Hintergrund durchführen, oder?
Typisches Testprotokoll:
Sie schaffen Treibhausbedingungen, indem Sie 100K Iterationen für 1,5 Sekunden auf demselben Tick durchführen. Ich hingegen habe absichtlich auf Ticks gewartet, die kein OnTick auslösten.
Wenn ich mir meine Handelsprotokolle ansehe, stelle ich fest, dass die SymbolInfoTick-Ausführung innerhalb weniger Millisekunden erfolgt. Und ich weiß zu 100%, dass die CPU zu diesem Zeitpunkt im Leerlauf war.
Es ist ganz einfach. Es gibt bedingt 1 Million Zecken pro Tag. Selbst eine Verlangsamung von 0,01 % der Ticks entspricht 100 Ticks pro Tag mit Verzögerungen. Sie werden sagen, dass das Unsinn ist. Ich würde sagen, es ist schlecht. Wenn ich bei einer Bestellung auf eine Verzögerung stoße, ist das ein potenzieller finanzieller Verlust.
Ich bin sehr dankbar, dass dieser Zweig nicht unbemerkt bleibt, und insbesondere an dieser Funktion wurde viel gearbeitet, um die Dinge zu beschleunigen. Allerdings war ich etwas überrascht, dass die schreckliche Krücke in bestimmten Situationen die normale Funktion übertreffen konnte. Und wenn Sie diese Verzögerung beseitigen würden, würden aus 100 potenziellen Verzögerungen pro Tag vielleicht 10 werden.
Ich sage, es ist viel besser als zu Beginn des Threads. Aber es gibt auch Zeiten, in denen das nicht gut ist. Und ich kann sehen, dass Sie sich nicht damit befassen wollen. Ich respektiere Ihre Entscheidung.
Oben wurde die Option "Snapshot" genannt , um aktuelle Preise zu erhalten. Es würde mir vollkommen genügen, wenn es auf dem Idle-CPU-Rechner nicht zu Verzögerungen im Millisekundenbereich käme.
Außerdem mache ich mir nicht nur Sorgen über die Geschwindigkeit von SymbolInfoTick, sondern auch über die Relevanz der zurückgegebenen Preise. Ich sehe, dass Sie sich diese Frage nicht stellen. Offensichtlich haben Sie beschlossen, sich das später anzusehen.
Sie schaffen Treibhausbedingungen, indem Sie 100K Iterationen innerhalb von 1,5 Sekunden auf demselben Tick durchführen. Ich hingegen habe gezielt auf Ticks gewartet, die nicht OnTick auslösen.
Bei der Durchsicht meiner Handelsprotokolle stelle ich fest, dass SymbolInfoTick einige Millisekunden lang läuft. Ich weiß zu 100 %, dass die CPU in diesem Moment voll im Leerlauf war.Es ist ganz einfach. An einem Tag gibt es bedingt 1 Million Zecken. Selbst eine Verzögerung von 0,01 % entspricht 100 Ticks pro Tag mit Verzögerungen. Sie werden sagen, dass das Unsinn ist. Ich würde sagen, es ist schlecht. Wenn ich bei einer Bestellung auf eine Verzögerung stoße, ist das ein potenzieller finanzieller Verlust.
Ich bin sehr dankbar, dass dieser Zweig nicht unbemerkt bleibt, und insbesondere an dieser Funktion wurde viel gearbeitet, um die Dinge zu beschleunigen. Allerdings war ich etwas überrascht, dass die schreckliche Krücke in bestimmten Situationen die normale Funktion übertreffen konnte. Und wenn Sie diese Verzögerung beseitigen würden, würden aus 100 potenziellen Verzögerungen pro Tag vielleicht 10 werden.
Ich sage, es ist viel besser als zu Beginn des Threads. Aber es gibt auch Zeiten, in denen das nicht gut ist. Und ich kann sehen, dass Sie sich nicht damit befassen wollen. Ich respektiere Ihre Entscheidung.
Oben wurde die Option "Snapshot" genannt , um aktuelle Preise zu erhalten. Es würde mir vollkommen genügen, wenn es auf dem Idle-CPU-Rechner nicht zu Verzögerungen im Millisekundenbereich käme.
Außerdem mache ich mir nicht nur Sorgen über die Geschwindigkeit von SymbolInfoTick, sondern auch über die Relevanz der zurückgegebenen Preise. Ich sehe, dass Sie sich diese Frage nicht stellen. Offensichtlich haben Sie beschlossen, sich das später anzusehen.
Das sind überhaupt keine warmen Bedingungen. Eine Schleife für 100000 Preisanfragen ohne Sleep() und dergleichen und in 20 Threads gleichzeitig ist ein offensichtlicher Stresstest. Nichts dergleichen dürfte unter realen Bedingungen auch nur annähernd möglich sein.
Wenn Sie glauben, dass in 1,5 Sekunden keine weiteren Ticks kommen - ok, machen Sie 10 Millionen Abfragen, es wird nichts ändern, Ihre "Krücke" funktioniert schlechter:Diese Ihre Aussage ist zu 100 % falsch:
Genau wie Ihre vorherige Aussage:
Der Zugriff auf Preise über SymbolInfoTick ist jetzt sehr schnell und vollständig von der Verarbeitung des Tick-Streams entkoppelt. Sie arbeiten mit einem vorgefertigten Preis-Cache, der sehr sparsam und schnell aktualisiert wird.
Alle "Verlangsamungen der Tickrate um 0,01 %" treten nur unter Stresstestbedingungen auf, und das ist ein großartiges Ergebnis. Unter normalen Bedingungen ist ein sehr schneller Zugriff gewährleistet.
Wenn Sie zugeben, dass "eine Menge Arbeit getan wurde, um SymbolInfoTick zu beschleunigen", dann sollten Sie mir glauben, dass die "Krücke", Preise über PositionSelectByTicket zu erhalten, keine bessere Lösung sein kann.
Aus einem einfachen Grund - die Implementierung von PositionSelectByTicket ist völlig identisch mit der ursprünglichen "langsamen" Implementierung von SymbolInfoTick.
Wie ich oben geschrieben habe, ist diese Implementierung nicht langsam im wörtlichen Sinne des Wortes, aber unter hoher CPU-Last hat sie eine höhere Wahrscheinlichkeit von Laufzeitausreißern (was in meinem letzten Test deutlich sichtbar ist).
Die Zeitangaben sind hier stark vom System-Task-Scheduler abhängig, der unter Last läuft, d.h. es kann Unterschiede von Betriebssystem zu Betriebssystem und sogar von Version zu Version geben.
Und je höher die Belastung ist, desto mehr testen Sie die Leistung des Task-Planers und nicht des Terminals.
Das ist das Ende des Themas der SymbolInfoTick-Leistung.
Wenn Ihre Experten eine Belastung auf dem Niveau von synthetischen Stresstests erzeugen, gibt es nur eine Lösung: "Das Eisen muss zu den Aufgaben passen".
Ich habe eine Frage zur Relevanz der von SymbolInfoTick angegebenen Ticks.
Situation:
1. Wir machen TimeCurretn(); wir erhalten die Zeit 18:00:00
2. SymbolInfoTick bei einem ungültigen Symbol ausführen. Wir erhalten ein Häkchen mit der Zeit 17:58:00.
3. schlafen(1)
4. Fügt einen SymbolInfoTick für das nicht linke Symbol hinzu. Wir erhalten ein Häkchen mit der Uhrzeit 17:59:00.
D.h., im vierten Element haben wir einen neuen Tick, der eine Minute anders ist als TimeCurretn().
Sehen Sie in dieser Situation ein Problem?
Wie kommt man seltener in diese Situation?
Ich habe eine Frage zur Relevanz der von SymbolInfoTick angegebenen Ticks.
Situation:
1. Wir machen TimeCurretn(); wir erhalten die Zeit 18:00:00
2. SymbolInfoTick für ein nicht beschriftetes Symbol ausführen. Wir erhalten ein Häkchen mit der Zeit 17:58:00.
3. schlafen(1)
4. Fügt einen SymbolInfoTick für das nicht linke Symbol hinzu. Wir erhalten ein Häkchen mit der Uhrzeit 17:59:00.
D.h., im vierten Element haben wir einen neuen Tick, der eine Minute anders ist als TimeCurretn().
Sehen Sie in dieser Situation ein Problem?
Wie kommt man seltener in diese Situation?
SymbolInfoTick sendet die vom Broker-Server empfangenen Daten. Was der Server sendet, ist das, was Sie bekommen.
Wenn Sie Fragen zum Tick-Stream haben, der von Ihrem Broker übertragen wird, müssen Sie sich an Ihren Broker wenden.