![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Für den Fall, dass jemand es nicht versteht, es ist die fxsaber-Bibliothek, die das Bremsen verursacht, wenn sie im Code eines anderen angewendet wird.
Anstatt ausdrücklich darauf hinzuweisen, fing er an, das Spiel mit dem Bremsen von Plattformen und dem Ausrutschen selbstmörderischer Beispiele zu spielen. Und als sich die Gelegenheit bot, zur wahren Ursache vorzudringen und die Angelegenheit zu bereinigen, hat er sie nicht genutzt.
Aus Gründen der lokalen Optimierung wurde der Verlaufscache für die Hauptanwendung vergiftet.Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
MT5 und Geschwindigkeit in Aktion
fxsaber, 2020.09.02 00:02
Es gab einen sauberen MQL5-Code, der von vielen reproduziert werden konnte. Die Chronologie des Threads erste Studie, anstatt spielen Verschwörungstheorie, dass jemand braucht Sie so sehr, dass er bereit ist, seine Zeit auf Sie für Schlammschlacht zu verbringen.
Du machst einen tollen Job als Truthahn. Es gab keine Diskussion über Bibliotheken hier in diesem Thread, da sie nicht konstruktiv ist.
Der Punkt ist, dass jemand, der es wagt, gemeinsam genutzte Bibliotheken zu verwenden, bei denen der from-input-Parameter nicht übereinstimmt, gebremst werden wird. Dies wird in der Dokumentation nirgends erwähnt. Wenigstens wurde etwas davon mit einer Zange aus Ihnen herausgeholt. Und als das erledigt war, beschuldigten sie Sie des Betrugs.
Diese Funktion von MQL sollte in die Dokumentation und den Funktionszweig aufgenommen werden. Führen Sie die sauberen MQL5-Skripte aus diesem Zweig auf den Builds aus, die dem Datum ihrer Erstellung entsprechen. Offenbar wurden so viele Korrekturen blindlings vorgenommen, nur für den Fall der Fälle.
Sie machen einen großartigen Job als Indie. Hier im Thread wurden keine Bibliotheken ausdrücklich erwähnt, weil das nicht konstruktiv ist.
Denn Sie haben Ihr Bestes getan, um nicht über Ihre Bibliotheken zu plaudern. In Anwesenheit dieser Bibliotheken. Mit dem ständigen Einwand "meins ist schneller". Sie haben also die Selbstschussanlage geschickt verdeckt, indem Sie darauf hingewiesen haben, wie langsam sie ist.
Der Punkt ist, dass es zu Verzögerungen kommt, wenn man es wagt, Bibliotheken zusammen zu verwenden, bei denen der "from-input"-Parameter nicht derselbe ist. Dies wird in der Dokumentation nirgends erwähnt. Wenigstens wurde Ihnen mit der Kneifzange etwas zu diesem Thema entlockt. Und als das erledigt war, beschuldigten sie Sie des Betrugs.
Diese Funktion von MQL sollte in die Dokumentation und den Funktionszweig aufgenommen werden. Führen Sie die sauberen MQL5-Skripte aus diesem Zweig auf den Builds aus, die dem Datum ihrer Erstellung entsprechen. Offenbar wurden so viele Korrekturen blindlings vorgenommen, nur für den Fall der Fälle.
In der HistorySelect-Dokumentation ist eindeutig festgelegt:
Wenn Sie mit großen Volumina arbeiten (und Sie haben nicht umsonst Tausende und Zehntausende von Geschäften in der Historie gezeigt), die einen atomaren/Snapshot-Zugriff erfordern, müssen Sie deren Kosten verstehen.
Zumal ich die technischen Details dieser Caches in diesem Thread sehr ausführlich erläutert habe.
Haben Sie umsonst versucht, jede Probe zu randomisieren und den Cache so weit wie möglich zu vergiften? Ist um Ihrer Position willen ein Selbstschuss in Ordnung?
Weil Sie alles getan haben, um Ihre Bibliotheken geheim zu halten. Deshalb haben Sie die selbstverschuldeten Fehler geschickt überdeckt, indem Sie damit prahlten, "wie langsam es ist".
99 % der Fehler werden auf diese Weise gefunden. Zunächst ist das seltsame Verhalten im großen Code zu finden. Dann findet die Lokalisierung die Ursache. Ich habe mir mehr Sorgen um die Bremsen gemacht.
Handelsfunktionen. Die Probleme sind fast überall.
In der HistorySelect-Dokumentation wird ausdrücklich darauf hingewiesen:
Ich frage mich, wer in diesem Text etwas zwischen den Zeilen gesehen hat? Ich persönlich habe es so verstanden (vor diesem Zweig), dass HistoryDealSelect und HistoryOrderSelect so geschrieben werden müssen.
Andernfalls sind Verzögerungen vorprogrammiert.
Wenn Sie mit großen Volumina arbeiten, die einen atomaren/Snapshot-Zugriff erfordern, müssen Sie sich über deren Kosten im Klaren sein.
Dies gilt umso mehr, als ich die technischen Einzelheiten dieser Caches in diesem Thread ausführlich erläutert habe.
Ich habe die notwendigen Informationen in diesem Thread gesammelt.
Haben Sie umsonst versucht, jede Probe zu randomisieren und den Cache so weit wie möglich zu vergiften? Ist um Ihrer Position willen ein Selbstschuss in Ordnung?
Sie können alles chronologisch in diesem Thread sehen. Das Problem wurde ursprünglich ohne Randomisierung dargestellt.
Dieser Thread ist ein großartiger Beweis dafür, wie man die Worte des Gegners verdrehen kann. Alle Quellen und ihre Ergebnisse werden hier gespeichert.
Warum kann das Terminal nicht einfach den Zwischenspeicher vergrößern, wenn der vollständige Verlauf erneut angefordert wird, und den fehlenden Bereich abrufen und zwischenspeichern? Damit scheint das Problem gelöst zu sein. Schließlich werden bei der Anforderung von Barren/Fahrscheinen fehlende Datenpakete zurückgegeben, so dass es einen Mechanismus dafür gibt.
Warum kann das Terminal nicht einfach den Cache erhöhen, wenn der vollständige Verlauf erneut angefordert wird, und den fehlenden Bereich abrufen und zwischenspeichern?
Dies ist bereits geschehen.
Wenn aber zwischen HistorySelect( 0, INT_MAX ) AufrufenHistorySelect( andere_Zeit, ... ), wird der Cache ab der anderen_Zeit neu aufgebaut und die nächsteHistorySelect( 0,... ) Anfrage führt zu einem neuen Cacheaufbau (wird langsamer sein).
Dies ist bereits geschehen.
Wenn jedoch zwischen den Aufrufen von HistorySelect( 0, INT_MAX )HistorySelect( andere_Zeit, ... ) aufgerufen wird, wird der Cache ab der anderen_Zeit neu aufgebaut, und die nächsteHistorySelect( 0,... )-Anforderung führt zu einem neuen Cache-Aufbau (der langsamer ist).
Wenn Sie es getan haben, ist es gut, die einzige Frage ist dann die nach der Bequemlichkeit der Arbeit mit den empfangenen Daten, vorausgesetzt, der Cache ist aufgebaut.
Ich habe die Handelsoperationen nicht so genau verstanden, aber wenn sich der Abfragebereich ändert, gibt es dann keine Möglichkeit, Daten innerhalb der Historie schnell und ohne rohe Gewalt zu suchen?
Ich bin nicht so tief in den Handel, aber wenn der Bereich der Abfrage ändert, dann gibt es keine Möglichkeit, schnell für Daten innerhalb der Geschichte ohne eine vollständige Aufzählung zu suchen?
Was nützt Ihnen dieses Wissen, wenn Sie es nicht nutzen?
Kein praktisches Problem = keine Frage.
OrderExist und PositionExist sind spezielle optimierte Funktionen, die das stupide Durchlaufen aller Aufträge oder Positionen auf der Suche nach Einträgen nach Symbol, Transaktionsart und Medzhik vermeiden.
Das Ergebnis ist eine Reihe von Tickets.
Mit diesen Funktionen können die Programme eine Menge Geld sparen. Vor allem, wenn offene Positionen und Aufträge massenhaft, ständig und wiederholt in Überschreitungsschleifen aufgerufen werden.
Wir werden in Zukunft effektivere Funktionen für den Zugriff auf umfangreiche Handelsdaten einführen.
Darüber hinaus wird die Sprache erheblich gestärkt und vereinfacht und mit leistungsfähigeren Funktionen ausgestattet.
"OrderExist und PositionExist" - nicht in der Dokumentation gefunden, wo kann man sie nachlesen?
Höchstwahrscheinlich nach der nächsten Version (jetzt im Beta-Stadium)