Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 49

Neuer Kommentar
 
fxsaber:

Wenn Sie unmittelbar nach den Wörtern if, else, while, for, do TAB drücken, gibt es eine kleine Zusatzkonstruktion...


f*cking hell... großartig, nach 5 Jahren, in denen ich mql kannte, habe ich es herausgefunden.

 

Schlussfolgerungen aus einem Gespräch im SD über ein angesprochenes Problem.

Es stellt sich heraus, dass die Zuweisung eines Wertes an eine String-Variable eine SEHR teure Operation ist.

Das ist so teuer, dass es wünschenswert ist, es möglichst zu vermeiden, bis die Entwickler diesen Punkt im Compiler verbessern, was wohl nicht bald geschehen wird.


Wenn Sie zum Beispiel einen echten Tick-Lauf für einen Monat auf der FIBO durchführen, wären das etwa 1 Million Ticks. Wenn Sie den Wert von PositionGetString bei jedem Tick abrufen und mit etwas vergleichen, wäre die Leistung akzeptabel, aber wenn Sie das Ergebnis der Funktion zunächst einer String-Variablen zuweisen, bevor Sie es vergleichen, würde sich die Dauer des Laufs um etwa eine Sekunde verlängern.


Wenn es wie eine Kleinigkeit aussieht, dann ist das eine falsche Vorstellung. Wenn ein solcher EA im Optimierungsmodus für mehrere tausend Durchläufe ausgeführt wird, bedeutet diese zusätzliche Sekunde zusätzliche Stunden an Wartezeit. D.h. eine harmlose String-Zuweisung kann bei der Optimierung zusätzliche Stunden Wartezeit verursachen. Seien Sie vorsichtig und berücksichtigen Sie diese Nuance.


In kodobase gibt es ein kleines Tool, mit dem Sie solche Fehler in verschiedenen Implementierungen derselben Handelslogik erkennen können. Schreiben Sie schnellen Code.

 
fxsaber:

Schlussfolgerungen aus einem Gespräch im SD über ein angesprochenes Problem.

Es stellt sich heraus, dass die Zuweisung eines Wertes an eine String-Variable eine SEHR teure Operation ist.

Das ist so teuer, dass es wünschenswert ist, es möglichst zu vermeiden, bis die Entwickler diesen Punkt im Compiler verbessern, was wohl nicht bald geschehen wird.


Wenn Sie zum Beispiel einen echten Tick-Lauf für einen Monat auf der FIBO durchführen, wären das etwa 1 Million Ticks. Wenn Sie den Wert von PositionGetString bei jedem Tick abrufen und mit etwas vergleichen, wäre die Leistung akzeptabel, aber wenn Sie das Ergebnis der Funktion zunächst einer String-Variablen zuweisen, bevor Sie es vergleichen, würde sich die Dauer des Laufs um etwa eine Sekunde verlängern.


Wenn es wie eine Kleinigkeit aussieht, dann ist das eine falsche Vorstellung. Wenn ein solcher EA im Optimierungsmodus für mehrere tausend Durchläufe ausgeführt wird, bedeutet diese zusätzliche Sekunde zusätzliche Stunden an Wartezeit. D.h. eine harmlose String-Zuweisung kann bei der Optimierung zusätzliche Stunden Wartezeit verursachen. Seien Sie vorsichtig und berücksichtigen Sie diese Nuance.


In kodobase gibt es ein kleines Tool, mit dem Sie solche Fehler in verschiedenen Implementierungen derselben Handelslogik erkennen können. Schreiben Sie einen schnellen Code.

Vielen Dank, ich hätte es nicht für möglich gehalten. Ich werde dies bei künftigen Entwicklungen berücksichtigen.

 

Ein einfaches Rätsel zur Schlafenszeit: Warum die gelben Ergebnisse?

struct INT
{
  int Array[];
  
  INT()
  {
    Print(__FUNCTION__); // до сюда не дойдет
  }
};

void OnStart()
{
  INT i = {0};
  
  Print(ArrayResize(i.Array, 5)); // -1
}
 
fxsaber:

Ein einfaches Rätsel zur Schlafenszeit: Warum die gelben Ergebnisse?

Weil die Struktur mit Nullen gepackt wird, nicht durch den Konstruktor, so dass die Array-Struktur falsch initialisiert wird, mag arrayresize solche Arrays nicht, mein Code stürzte bei einer solchen Größenänderung ab.
 
Kombinator:
Weil die Struktur mit Nullen gepackt wird, nicht der Konstruktor, so dass die Array-Struktur falsch initialisiert wird, mag arrayresize solche Arrays nicht, mein Code stürzte bei einer solchen Größenänderung überhaupt ab.

Es ist gut, dass alle darüber Bescheid wissen.

 
Slawa:

Sie bezieht sich auf GetMicrosecondCount. Es gibt keine eindeutige Methode, um festzustellen, ob der Server dadurch verlangsamt wird. Sie kann eine indirekte Wirkung haben. Daher ist es besser, die systemeigene Funktion GetTickCount

GetMicrosecondCount wird verwendet, um kurze Zeiträume der Codeausführung zu messen. Um eine große Anzahl von OnTick-Ausführungen zu messen, ist es besser, GetTickCount zu verwenden.

Versuchen Sie, GetMicrosecondsCount anstelle von GetTickCount zu verwenden, wenn Sie stabile Ergebnisse erhalten. Sie werden mir hier davon erzählen. Vielleicht mache ich mir zu viele Gedanken darüber.

Ihre Hypothese hat sich als richtig herausgestellt, ein mehrfacher Aufruf von GetMicrosecondsCount verursacht schreckliche Verzögerungen im Tester. GetTickCount hat jedoch die gleiche Wirkung.
 
fxsaber:

Schlussfolgerungen aus einem Gespräch im SD über ein angesprochenes Problem.

Es stellt sich heraus, dass die Zuweisung eines Wertes an eine String-Variable eine SEHR teure Operation ist.

Das ist so teuer, dass es wünschenswert ist, es möglichst zu vermeiden, bis die Entwickler diesen Punkt im Compiler verbessern, was wohl nicht bald geschehen wird.


Wenn Sie zum Beispiel einen echten Tick-Lauf für einen Monat auf der FIBO durchführen, wären das etwa 1 Million Ticks. Wenn Sie den Wert von PositionGetString bei jedem Tick abrufen und mit etwas vergleichen, wäre die Leistung akzeptabel, aber wenn Sie das Ergebnis der Funktion zunächst einer String-Variablen zuweisen, bevor Sie es vergleichen, würde sich die Dauer des Laufs um etwa eine Sekunde verlängern.


Wenn es wie eine Kleinigkeit aussieht, dann ist das eine falsche Vorstellung. Wenn ein solcher EA im Optimierungsmodus für mehrere tausend Durchläufe ausgeführt wird, bedeutet diese zusätzliche Sekunde zusätzliche Stunden an Wartezeit. D.h. eine harmlose String-Zuweisung kann bei der Optimierung zusätzliche Stunden Wartezeit verursachen. Seien Sie vorsichtig und berücksichtigen Sie diese Nuance.


In kodobase gibt es ein kleines Tool, mit dem Sie solche Fehler in verschiedenen Implementierungen derselben Handelslogik erkennen können. Schreiben Sie einen schnellen Code.

struct STRUCT
{
  string Str;
  
  string Get() const { return(this.Str); }
};

void OnStart()
{
  STRUCT Struct;
  
  Print(Struct.Str);
  Print(Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber:

Es stellt sich heraus, dass die Zuweisung eines Wertes an eine String-Variable eine SEHR teure Operation ist.

...

Wenn Sie das Ergebnis einer Funktion vor dem Vergleich zunächst einer String-Variablen zuweisen und dann vergleichen, verlängert sich die Laufzeit um etwa eine Sekunde.

Meines Erachtens liegt das Problem nicht so sehr in der teuren Zuweisung, sondern in der Tatsache, dass der Compiler diese unnötige Zuweisung aus irgendeinem Grund nicht aus dem Code herausschneidet, obwohl er das sollte. Das heißt, der kompilierte Code sollte in beiden Fällen der gleiche sein.
 
Alexey Navoykov:
So wie ich es verstehe, liegt das Problem nicht so sehr in der teuren Zuweisung, sondern darin, dass der Compiler diese unnötige Zuweisung aus irgendeinem Grund nicht aus dem Code herausschneidet, obwohl er das sollte. D.h. der kompilierte Code sollte in beiden Fällen gleich sein.

Dies ist ein kleines Problem. Ja, der Compiler-Optimierer weiß noch nicht, wie er solche String-Momente optimieren soll. Das Problem der Verlangsamung liegt jedoch in der String-Zuweisung.

Schreiben Sie Code, der vom Compiler nicht optimiert werden kann, und nehmen Sie gleichzeitig Zuweisungen darin vor. Und Sie werden sehen, was eine Verlangsamung ist.

Das Beispiel des Lesens eines String-Feldes einer Struktur durch eine Funktion ist genau die Art und Weise, wie das Lesen von Positionseigenschaften in MT4/5 implementiert ist.

In MT4 wird die gleiche OrderSymbol() gebremst, wenn sie in MT5 implementiert ist. Die Entwickler selbst versuchen, ihren Funktionen Strings über Links zu übergeben.

Wenn Sie also etwas wie folgt schreiben

if ((OrderSymbol() == Symb) && (OrderMagicNumber == Magic))

es ist immer besser, die OrderSymbol()-Bedingung an das Ende der allgemeinen Bedingung zu schieben.


Ich habe bei der Verwendung von TesterBench eine offensichtliche Verlangsamung bei scheinbar glatten Oberflächen festgestellt.

1...424344454647484950515253545556...247
Neuer Kommentar