
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
Bitte geben Sie einen rudimentären Diagramm-Code für diese Idee. Auf den ersten Blick scheint es sich um ein völliges Missverständnis zu handeln.
Während der Ausführung der Funktion OnMain gibt es keine Möglichkeit, den Status der aktuellen realen Warteschlange zu erfahren. Die einzige Abhilfe ist ein Spyware-Programm, wie im Link angegeben.
In seiner einfachsten Form:
Sie müssen nur den Ansatz für die Berechnungen selbst ändern (so oft wie die Aufgabe es erfordert eine Zwischenrückkehr durchführen). Aber wenn es schwierig ist, bedenken Sie beim 1. Schritt, dass OnMain für Sie nicht existiert (Sie verschieben den Hauptcode nicht in OnMain, sondern in On2XX), bzw. in OnMain brauchen Sie nichts zu lernen
Die Krücken werden in die falsche Richtung gebaut:
Lassen Sie die OnXXX-Funktionen nur die Ereignisse (Parameter) in die Warteschlange kopieren und die Hauptfunktion OnMain aufrufen. Verschieben Sie ihren gesamten Code in doppelte On2XX-Funktionen. Und rufen Sie diese sich duplizierenden On2XX-Funktionen von OnMain aus in der von Ihnen benötigten Reihenfolge auf, wobei Sie ihnen wiederum die Daten aus den Warteschlangen als Parameter übergeben.
Führen Sie dann Messungen durch und zeigen Sie den Geschwindigkeitszuwachs, und dann können Sie vorschlagen, MMS mit geeigneten Funktionen zu ergänzen. Aber warum etwas hinzufügen, wenn man hier und jetzt schon alles selbst gemacht hat?
Das ist nicht das, worüber du schreibst.
Das Problem ist, dass die Funktionalität des Füllens von Feldern in Eingabevariablen der Funktion "OntaredeTransaction" nicht der Beschreibung in der Hilfe entspricht, zum Schlimmeren:
d.h. viele Felder werden in Aufrufen und sogar im letzten Aufruf von TRADE_TRANSACTION_HISTORY_ADD nicht gefüllt.
Folglich quälen sich alle Händler hier, diese fehlenden Parameter im Moment der Ankunft irgendwie zu bestimmen.
Es gab viele Diskussionen hier, suchen Sie einfach im Forum - schlechte "OntaredeTransaction"-Funktionalität verursacht zusätzliche Kosten sowohl in Zeit und "lädt" Händler mit zusätzlicher Zeit für die Entwicklung von angemessen funktionierenden Code (dh riesige Zeitverluste und kolossale Ineffektivität auf Gemeinschaftsebene).
Die aktuellen Antworten der Entwickler lauten: "Wenn Sie ein Marktausführungssymbol haben, hat es einen Preiswert von Null; es sollte so sein" (Link).(Link) - das ist wieder einmal UNNORMAL -
das Fehlen erschöpfender Werte im letzten Funktionsaufruf führt zu einer Menge zusätzlicher Arbeit.
GeschichteAuswählen.
Dies ist eine wahnsinnig teure Funktion. Und leider kann keine noch so gute Zwischenspeicherung die Geschwindigkeit akzeptabel machen.
Bei EAs für Schlachtfelder ist es zum Beispiel wichtig, mit aktuellen Daten zu arbeiten. Insbesondere, dass die Ticks von Market Watch und CopyTicks möglichst nicht veraltet sind.
Dazu gibt es zwar nicht sehr gute, aber erzwungene Mechanismen zur Überprüfung der Relevanz aktueller Preisdaten. Ein Teil dieses Mechanismus besteht darin, Situationen zu erkennen, in denen ein Handel mit einem Symbol später als der letzte Tick stattgefunden hat. Das passiert nicht selten, daher ist es wichtig zu wissen, ob der aktuelle Tick noch aktuell ist oder nicht.
Für diese Erkennung müssen Sie auf die Historie der letzten Geschäfte zugreifen können. Dies geschieht mit Hilfe von HistorySelect auf die folgende schematische Weise.
Leider dauert ein solcher Aufruf von HistorySelect 5-30 Millisekunden (ich habe es selbst in Release-EX5 gemessen). Wenn der Expert Advisor mehrere solcher Aktualisierungen in OnTick durchführt (dies sollte nach jeder Pause geschehen, z. B. nach jedem OrderSend), dann wird alles wahnsinnig teuer/langwierig. HistorySelect kann insgesamt mehrere Sekunden in einem einzigen OnTick verbrauchen.
Liebe Entwickler, warum ist es so teuer? Diese Funktion kann bei richtiger Implementierung sofort ausgeführt werden.
Haben Sie Beweise für "ein solcher Aufruf von HistorySelect dauert 5-30 Millisekunden"?
Wenn ich Ihre Idee richtig verstanden habe, dann sollte der Testcode wie folgt aussehen:
So funktionieren 100000 Abfragen:
Haben Sie Beweise für "ein solcher Aufruf von HistorySelect dauert 5-30 Millisekunden"?
Wenn ich Sie richtig verstanden habe, dann sollte der Testcode so aussehen:
So funktionieren 100.000 Abfragen:
Haben Sie Beweise für "ein solcher Aufruf von HistorySelect dauert 5-30 Millisekunden"?
Wenn ich Sie richtig verstanden habe, dann sollte der Testcode so aussehen:
So funktionieren 100.000 Abfragen:
Ihr Skript ausführen.
Starten Sie ein anderes Skript.
Normale Kampfanzahl. Nicht HFT.
Übrigens hat Ihr Skript gezeigt, dass HistorySelect alles jedes Mal neu berechnet. Und die Eingabeparameter haben sich nicht geändert, die History-Tabelle wurde nicht aktualisiert, andere HistorySelect-Funktionen wurden nicht aufgerufen.
Ihr Skript ausführen.
Dann sind Details erforderlich.
Mein Test lief auf dem nicht gerade schnellsten "Intel Xeon E5-2630 v4 @ 2.20GHz" mit einer Menge anderer Prozesse im Hintergrund.
Die Historie meines Testkontos zeigt 31315 mehr oder weniger gleichmäßige Aufträge seit 2009, darunter 8 Aufträge für heute.
Vielleicht hatten Sie zur gleichen Zeit ein Skript oder einen Expert Advisor laufen, der die Terminal-Datenbanken drastisch belastet hat. Versuchen Sie es mit einem "sauberen" Terminal.
Informativerer Test:
Drei Durchgänge:
Dann sind Details erforderlich.
Mein Test lief auf dem nicht gerade schnellsten "Intel Xeon E5-2630 v4 @ 2.20GHz" mit vielen anderen Prozessen im Hintergrund.
Das Testkonto hatte seit 2009 mehr oder weniger gleichmäßig 31315 Aufträge, darunter 8 Aufträge für heute.
Vielleicht hatten Sie zur gleichen Zeit ein Skript oder einen Expert Advisor laufen, der die Terminal-Datenbanken drastisch belastet hat. Versuchen Sie es mit einem "sauberen" Terminal.
Leeren Sie das Terminal auf demselben Konto und Rechner.
Auf anderen Konten und Terminals das gleiche Bild. Konfiguration.
Ich bitte die Leser, ihre Ergebnisse zu diesem Skript mitzuteilen.
Ein informativerer Test:
Drei Anläufe:
Leeres Terminal 2460.
ZS Run on empty account.
Die Geschwindigkeit scheint stark von der Anzahl der Trades und nicht von den Aufträgen beeinflusst zu werden.
Leeren Sie das Terminal auf demselben Konto und Rechner.
Auf anderen Konten und Terminals das gleiche Muster. Konfiguration.
Ich bitte die Leser, ihre Ergebnisse zu diesem Skript zu nennen.
Das beweist zwar nichts, aber die Tatsache, dass sich die Zeit mit jedem neuen Durchlauf (auf einem anderen Symbol) erhöht, ist alarmierend...
Sie müssen auf einem Konto mit einer langen Handelsgeschichte laufen.