Event-Stream. Wie kann man das Ereignis kontrollieren und in den Leerlauf versetzen? (+ gelöst) - Seite 3

Neuer Kommentar
 

Yedelkin:

Ähnlich verhält es sich, wenn bereits ein Ereignis ChartEventin der Warteschlange des mql5-Programms vorhanden ist oder ein solches Ereignis gerade behandelt wird .

Hmm. Das ist wirklich schlimm. Theoretisch bedeutet dies, dass, wenn z. B. ein Indikator und ein Expert Advisor unabhängig voneinander Ereignisse verwenden, es in beiden Fällen zu Auslassungen kommen kann.

Dann macht es keinen Sinn, das Ereignis als zuverlässiges Mittel zur Datenübermittlung zu nutzen.

Schade.

 
sergeev:

Ihre Frage "Mit welcher ungefähren Häufigkeit sollten benutzerdefinierte Ereignisse gesendet werden, damit sie die Warteschlange nicht überfüllen?

Meine Antwort auf der ersten Seite lautet "mit der Häufigkeit der OnChartEvent-Aufrufe".

Das heißt, ein Ereignis ist ein OnChartEvent. Es sollten nicht mehr als zwei Ereignisse dazwischen liegen.

Das war's mit der Mathematik.

Noch einmal: Lesen Sie die erste Seite. Ich habe gezeigt, wie man die Anhäufung von Benutzerereignissen vermeiden kann, wenn ein Terminalereignis anstelle eines Benutzerereignisses verarbeitet wird. So einfach ist das.

Noch einmal, höflich :) Sie haben Ihr Problem gelöst, ich versuche, meines zu lösen, allerdings mit einem anderen Plan. Beim Lesen der Diskussion habe ich keine Antwort auf meine Fragen gefunden. Sie haben meine Hauptfrage (zur Speichernutzung) noch immer nicht beantwortet (falls Sie das tun wollen).

Lassen Sie mich das erklären. Ich habe nicht die Aufgabe "irgendeine Funktion zu aktualisieren, aber schneller als MQL vorschlägt mit einem Timer". Umso mehr, als es am Ende auf so kluge Weise vorgeschlagen wurde. Die benutzerdefinierten Ereignisse von mehreren Charts mit variabler Frequenz bombardieren einen separaten Chart, der einen Expert Advisor und eine Event-Handler-Funktion enthält. Dementsprechend passt das Ergebnis Ihrer eng gefassten Aufgabe(EventChartCustom innerhalb von OnChartEvent) überhaupt nicht in mein Schema der Arbeit mit benutzerdefinierten Ereignissen.

 

Yedelkin:

Zur Klarstellung. Ich habe nicht die Aufgabe, irgendeine Funktion schneller zu aktualisieren, als es MQL per Timer vorschlägt". Schon gar nicht auf eine so clevere Art und Weise, wie am Ende vorgeschlagen. Die benutzerdefinierten Ereignisse von mehreren Charts mit variabler Frequenz bombardieren einen separaten Chart, der einen Expert Advisor und eine Event-Handler-Funktion enthält. Dementsprechend passt das Ergebnis Ihrer eng gefassten Aufgabe(EventChartCustom innerhalb von OnChartEvent) überhaupt nicht in mein Schema der Arbeit mit benutzerdefinierten Ereignissen.

Es ist nicht kompliziert, es ist einfach. Wenn Sie es nicht verstehen können, ist das nicht mein Problem. das ist eine

Es ist nicht innerhalb von OnChartEvent, es ist über den ganzen Code verstreut. Sie erfinden Ihre eigenen, engen Einschränkungen für den Betrieb. Das sind zwei.

Wenn sich bereits ein Ereignis ChartEvent in der Warteschlange von mql5-program befindet oder ein solches Ereignis bearbeitet wird, wird ein neues Ereignis dieses Typs nicht in die Warteschlange gestellt.

Dies ist entweder ein Fehler oder ein Dokumentationsfehler oder fehlende Bedingungen.

Alle Ereignisse werden erfolgreich in die Warteschlange aufgenommen und keine Ereignisse werden verworfen. Sonst wäre mein Thema nicht erschienen.

Ich versuche, mein anderes Problem zu lösen
welche Auswirkungen hat Ereignis Warteschlange Überlauf auf RAM-Größe? Wenn sich herausstellt, dass die Ereigniswarteschlange überläuft, wohin gehen dann die Ereignisse, die die Warteschlange überlaufen lassen?

Haben Renat und Rosh diese Frage bereits beantwortet?
 
Rosh:

Wenn ein Ereignis verworfen wird, wird es einfach nicht in die Warteschlange aufgenommen. Der Speicher wächst nicht.

Puh! Das ist die Hauptsache, die ich verstehen wollte. Und da TheXpert sagte, dass nur ein paar MB für die Warteschlange selbst verwendet werden, ist es wahrscheinlich, dass das Speicherleck woanders liegt... Bis zum Beweis des Gegenteils sollten wir uns an diese Aussage halten.

Rosh:

Wenn diese Art von Problem auftritt, dann ist die Lage sehr schlecht. Ich denke, die überfüllte Ereigniswarteschlange ist der letzte Ort, an dem man nach Speicherproblemen suchen sollte.

Ja, ich versuche, überall zu suchen, wo ich kann.

Beachten Sie jedoch, dass von den drei disqualifizierten Sachverständigen mindestens zwei mit einem benutzerdefinierten Ereignisstrom gearbeitet haben (der Autor des dritten Sachverständigen antwortet nicht auf die Anfrage). Lizar (das mit benutzerdefinierten Ereignissen arbeitet) hat ebenfalls einen hohen Speicherverbrauch. Und tol64 hat einen extrem niedrigen Speicherverbrauch, weil die Benutzerereignisse seltener als einmal pro Minute verwendet werden, wenn ich es richtig verstanden habe. Es stellt sich also heraus, dass Sie die Effizienz der Implementierung des Konzepts der benutzerdefinierten Ereignisse anzweifeln müssen, bis Sie eine erschöpfende Antwort erhalten.

 
Yedelkin:

Beachten Sie jedoch, dass von den drei disqualifizierten EAs mindestens zwei mit einem Strom von benutzerdefinierten Ereignissen arbeiteten (der Autor des dritten antwortet nicht auf die Anfrage). Lizar (das mit benutzerdefinierten Ereignissen arbeitet) hat ebenfalls einen hohen Speicherverbrauch. Und tol64 hat einen extrem niedrigen Speicherverbrauch, weil die Benutzerereignisse seltener als einmal pro Minute verwendet werden, wenn ich es richtig verstanden habe. Es stellt sich also heraus, dass Sie die Effizienz der Implementierung des Konzepts der benutzerdefinierten Ereignisse anzweifeln müssen, bis Sie eine erschöpfende Antwort erhalten.

Und vergessen wir nicht, dass der EA die Ereignisse von den Indikatoren erhalten hat, die in vielen Tools und Zeitrahmen ausgeführt wurden, insgesamt etwa 80, wenn ich mich richtig erinnere. Jeder Indikator verbraucht Ressourcen für Indikatorpuffer, da liegt der Hund begraben.
 
sergeev:

es ist nicht kompliziert, es ist einfach. Wenn Sie es nicht verstehen können, ist das nicht mein Problem.

So wie ich es verstanden habe, habe ich geschrieben, dass es kompliziert ist. Sonst hätte ich es nicht angerührt.

sergeev:

Es ist nicht innerhalb von OnChartEvent, es ist im gesamten Code. Du machst dir deine eigenen engen Grenzen, wie es funktioniert. Das sind zwei.

Ja, ja, EventChartCustom befindet sich nicht innerhalb von OnChartEvent, sondern quasi außerhalb. Schauen Sie sich nun Ihren eigenen Code an:

void OnChartEvent(int iview, int id, long lparam, double dparam, string sparam)
{
    if (id==CHARTEVENT_CUSTOM+VM_IDLE)
    {
      ... 
    }
    EventChartCustom(m_chart, VM_IDLE, (long)event_idle, 0, ""); // отправили событие с указанием последнего счетчика
}

Offensichtlich in diesem Code EventChartCustom ist nicht innerhalbOnChartEvent, und ich bin sehr falsch :)

sergeev:

Es ist entweder falsch oder ein Fehler oder ein Dokumentationsfehler oder eine unterschätzte Bedingung.

Alle erfolgreichen Ereignisse bleiben in der Warteschlange, und kein Ereignis wird verworfen. Sonst wäre mein Thema nicht erschienen.

Es gibt noch mindestens eine weitere Version: In Ihrem speziellen Fall läuft die Warteschlange einfach nicht über (aus Gründen der Code-Effizienz), so dass es keinen Grund gibt, Ereignisse zu verwerfen.

 
Yedelkin:

Es gibt noch mindestens eine weitere Variante: In Ihrem speziellen Fall läuft die Warteschlange einfach nicht über (aus Gründen der Code-Effizienz), so dass keine Ereignisse verworfen werden.

Hier ist mein spezieller Fall, mit dem ich begonnen habe, um zu zeigen, dass identische Ereignisse nicht verworfen werden

https://www.mql5.com/ru/forum/5091#comment_112780

Dort habe ich geschrieben, warum der Überlauf auftritt.

Ja, ja, EventChartCustom befindet sich nicht innerhalb von OnChartEvent, sondern quasi außerhalb. Schauen Sie sich nun Ihren eigenen Code an:

Gehen Sie der Sache auf den Grund! Ich habe eine Demonstration des Problems und seiner Lösung gezeigt. Dieser EventChart-Aufruf kann an jeder beliebigen Stelle des Codes erfolgen.

 
Rosh:
Und vergessen wir nicht, dass der Expert Advisor die Ereignisse von den Indikatoren erhielt, die auf vielen Tools und Zeitrahmen liefen, insgesamt etwa 80, wenn ich mich richtig erinnere. Jeder Indikator verbraucht Ressourcen für Indikatorpuffer, und genau da liegt der Hund begraben.
Sprechen Sie von Japanern? Nun, in meinem Fall ist es einfacher: Ich habe einen universellen Indikator mit 8 oder 15 berechneten Indikatorpuffern, die auf 6 Instrumenten in einem Zeitrahmen laufen. D.h. es gibt nur 6 Indikatoren. Und theoretisch kann ein solches System 2 GB in einer Woche verbrauchen?
 
Yedelkin:
Sprechen Sie von den Japanern? Nun, in meinem Fall ist es einfacher: ein universeller Indikator mit 8 oder 15 Berechnungsindikatorpuffern, der auf 6 Instrumenten in einem Zeitrahmen läuft. D.h. es gibt nur 6 Indikatoren. Theoretisch kann ein solches System 2 GB in einer Woche verbrauchen?
Lesen Sie den Artikel Verringerung des Speicherverbrauchs für Hilfsindikatoren, er könnte nützlich sein.
 
Rosh:
Lesen Sie den Artikel Reducing Memory Consumption of Auxiliary Indicators, er könnte nützlich sein.

Danke, da habe ich schon alles optimiert :) Soweit ich mich erinnere, auch mit Blick auf diesen Artikel. Ich werde auf die nächste Stufe der Erleuchtung warten müssen :)

Ist es möglich, den Expert Advisor und den Indikator separat zu bestimmen, wenn sie über benutzerdefinierte Ereignisse zusammenarbeiten?

1234567
Neuer Kommentar