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
Drucken und Alert sind nicht asynchron?
Ich wollte diese Funktionen asynchron machen. Versucht eine Implementierung durch ChartEvent - es funktioniert. Aber es ist sehr langsam. Ich hatte das hier ausgegraben.
Auf eine so teure Funktion an kritischen Stellen wurde verzichtet.
Zum Thema "Alert".
Bisher können wir mit Sicherheit sagen, dass Alert an kritischen Stellen nicht möglich ist. Asynchronität ist erforderlich.
Reproduziert die SymbolInfoTick-Bremsen. Und kein Stresstest. Die praktische Notwendigkeit zwingt Sie, es so zu schreiben.
Folgen Sie dieser Anleitung für eine schnelle Wiedergabe.
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Synchroner OrderSend meldet erfolgreiche Ausführung schneller als Ping zum Handelsserver
fxsaber, 2020.09.30 20:36
Auf einem schnellen Rechner wird das Ergebnis mit 30 Zeichen in Market Watch angezeigt.
Ich hoffe, ich bin nicht der Einzige, der sich fortpflanzt. Natürlich ist die Verzögerung nicht so groß wie zuvor gezeigt. Aber hier wird es möglich sein, den Ursachen viel schneller auf den Grund zu gehen.
ZZY TimeCurrentMsc wird in MQL5 aus irgendeinem Grund nicht eingegeben, trotz wiederholter Anfragen.
Eine so teure Funktion wurde an kritischen Stellen aufgegeben.
Dies ist ein erheblicher Nachteil. Denn das MQL-Ereignismodell ist unvollständig - es gibt kein Null-Ereignis, d. h. das Ereignis, das aufgerufen wird, wenn keine anderen Ereignisse in der Warteschlange vorhanden sind. Es kann durch ein benutzerdefiniertes Ereignis emuliert werden. Aber unter Berücksichtigung dieses Nachteils ist das Ereignismodell für diejenigen, die an Geschwindigkeit interessiert sind, bedeutungslos
EventChartCustom ist teuer.
Wie sieht es ohneChartFirst() aus?
Wie wäre es ohne ChartFirst()?
Es ist teurer, an die Karte eines anderen Unternehmens zu senden als an die eigene.
Dies ist ein erheblicher Mangel. Denn das MQL-Ereignismodell ist unvollständig - es gibt kein Null-Ereignis, d. h. ein Ereignis, das aufgerufen wird, wenn keine anderen Ereignisse in der Warteschlange vorhanden sind. Es kann durch ein benutzerdefiniertes Ereignis emuliert werden. Aber angesichts dieses Nachteils ist das ereignisbasierte Modell für diejenigen, die an Geschwindigkeit interessiert sind, bedeutungslos
Mit OnTimer können Sie Hintergrundgespräche mit einer Frequenz von bis zu 16 ms führen.
Richtig, d.h. wir verlieren mindestens16ms bis zum Nichts (wir können frühestens zurückkommen).Und wir konnten sie nicht verlieren, wenn es ein kostenloses Null-Ereignis oder kostenlose benutzerdefinierte Ereignisse gab. Und nun funktioniert das Ereignismodell im folgenden Fall nur begrenzt:
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
MT5 und Geschwindigkeit in Aktion
fxsaber, 2020.10.06 01:27
Sie sind nicht auf dem Laufenden. Nehmen wir an, Sie müssen zwei Positionen in OnTick eröffnen. Der erste OrderSend dauert einige Millisekunden. Danach müssen Sie einen Schnappschuss machen. Und dann sollte der zweite OrderSend aufgerufen werden.
Nur OnTick kann Hunderte von Millisekunden lang ausgeführt werden. Und Sie schlagen vor, ein paar OnTimer zu knipsen.
Zum Thema "Alert".
Im Moment kann man mit Sicherheit sagen, dass Alert nicht an kritischen Stellen eingesetzt werden kann. Asynchronität ist erforderlich.
Warnung mit einem Druck, können Sie versuchen, es mit einem schnellen Schreiben irgendwo zu ersetzen.
Native Sql im Speicher kommt mir in den Sinn
Ich habe keinen Schnappschuss vorgeschlagen, sondern auf eine direkte Frage zum Millisekunden-Timer geantwortet.
Ich nutze oft die Tatsache, dass der Tester genau einen Millisekunden-Timer und keinen Sekunden-Timer hat. Der Beweis.
Ergebnis.
Zwischen Öffnungs- und Schließzeit der Position liegen genau 29 ms.