Gemeinkosten für die PLO

 

Im Zusammenhang mit einer ressourcenintensiven Aufgabe stellt sich die Frage, wie hoch der Overhead bei der Verwendung von OOP im Vergleich zur herkömmlichen prozeduralen Programmierung ist.

Hat jemand solche Tests durchgeführt?

Ich interessiere mich für den Unterschied zwischen:

  1. Funktionsaufruf mit Parametern
  2. Funktionsaufruf ohne Parameter
  3. Makroaufruf mit der Funktionalität der obigen Funktion
  4. Funktionsaufruf - Methode einer Klasse
  5. Aufruf einer virtuellen Funktion

 

Über welche Art von Gemeinkosten reden wir?

Wenn es sich um Maschinencode handelt, dann ruft die virtuelle Funktion meines Wissens die Prozedur indirekt über die virtuelle Funktionstabelle auf. Aber bei normalen Funktionen ist es ein direkter Anruf. Ich denke, es gibt sehr wenig Overhead.

Der Aufwand für die Programmierer ist viel wichtiger - das Schreiben und die Wartung des Codes, die Fehlerbehebung...

 

Funktionen ohne Parameter sind schneller als Funktionen mit Parametern.

 
Dmitry Fedoseev:

Funktionen ohne Parameter sind schneller als Funktionen mit Parametern.


Natürlich habe ich 2 Jahre lang in Assembler gepaukt )) Für eingebettete Prozessoren stimmt das, aber C++ ist immer noch C++. Auch eine Funktion ohne Parameter hat einen Prolog und einen Epilog, der ebenfalls Zeit benötigt.

Am schnellsten geht es natürlich, wenn Sie ein Makro verwenden, das wie eine Funktion aussieht. Es ist schade, dass es keine Inline-Funktionen in MQL gibt, aber Makros sind ein Ersatz für

 
George Merts:

Über welche Art von Gemeinkosten reden wir?

Wenn es sich um Maschinencode handelt, dann ruft die virtuelle Funktion meines Wissens die Prozedur indirekt über die virtuelle Funktionstabelle auf. Und bei normalen Funktionen ist es ein direkter Anruf. Ich denke, es gibt sehr wenig Overhead.

Der Aufwand für den Programmierer ist viel wichtiger - Schreiben und Warten des Codes, Fehlerkorrektur...


Natürlich ist uns der Zeitaufwand für die Ausführung egal - diese zusätzlichen Kilobytes spielen keine Rolle. Diese zusätzlichen Kilobytes sind uns egal.

 

Ein Makro wäre natürlich am schnellsten.

 
Alexey Volchanskiy:

Der schnellste Weg ist natürlich ein Makro, das als Funktion konzipiert ist. Schade, MQL hat keine Inline-Funktionen, aber ein Makro wäre ein Ersatz

Rinat sagte, dass MT eine seriöse Inline-Funktion hat und gute Ergebnisse liefert.

 
George Merts:

Rinat sagte, dass MT - ein ernsthafter Inliner - funktioniert und gute Ergebnisse liefert.


Ja, nach meinen persönlichen Beobachtungen hängt die Arbeit des Inliners in MT4 von der Stack-Größe (für Variablen im Stack zugewiesener Speicher) und der Anzahl der Variablen ab.
Aber in MT5 scheint die Abhängigkeit von der Stack-Größe beseitigt zu sein und der Optimierer ist dort im Allgemeinen hilfreicher.

 
Alexey Volchanskiy:

Im Zusammenhang mit einer ressourcenintensiven Aufgabe stellt sich die Frage, wie hoch der Overhead bei der Verwendung von OOP im Vergleich zur herkömmlichen prozeduralen Programmierung ist.

Hat jemand solche Tests durchgeführt?

Ich interessiere mich für den Unterschied zwischen:

  1. Funktionsaufruf mit Parametern
  2. Funktionsaufruf ohne Parameter
  3. Makroaufruf mit der Funktionalität der obigen Funktion
  4. Funktionsaufruf - Methode einer Klasse
  5. Aufruf einer virtuellen Funktion

Wenn gebrauchsfertige OOP-Bibliotheken verfügbar sind, verkürzt sich die Entwicklungszeit der Anwendung. Die Ausführungsgeschwindigkeit kann sich beim Aufruf der virtuellen Funktion verlangsamen.

Die einzige Nuance ist die Verfügbarkeit von guten OOP-Bibliotheken.

Die "Standardbibliothek" verletzt meinen Sinn für Schönheit und bringt mich dazu, eine DLL zu verwenden und leise in C++ zu programmieren.


 
George Merts:

Rinat sagte, dass in MT - eine ernsthafte Inliner funktioniert, und gibt gute Ergebnisse.

Ja, der Inliner ist sehr aggressiv und automatisch.

Auch der x64-Code-Optimierer ist der 32-Bit-Version weit voraus (dieser Zweig wurde komplett eingestellt und nicht weiterentwickelt). Außerdem kann der x64-Optimierer die meisten virtuellen Funktionen in direkte und Inline-Aufrufe umwandeln. Schließlich sind virtuelle Funktionen oft degeneriert.

Der eigentliche Overhead liegt jedoch bei den Referenzoperationen und der Steuerung dynamischer Indizes. Sie müssen die ganze Zeit kontrolliert werden.

 
Alexey Volchanskiy:

Im Zusammenhang mit einer ressourcenintensiven Aufgabe stellt sich die Frage, wie hoch der Overhead bei der Verwendung von OOP im Vergleich zur herkömmlichen prozeduralen Programmierung ist.

Natürlich kosten die netten Funktionen von OOP Ressourcen und zeitaufwändige Fehlersuche. OOP macht nur Sinn als bequeme Textumhüllung oder bei minimaler Verwendung zur Laufzeitinitialisierung... Eigentlich war OOP nur eine Marketingmaßnahme von Microsoft, um die Kosten für die Arbeitszeit der Programmierer zu erhöhen und den Kauf fortschrittlicherer Geräte zu fördern. Und sie sind selbst nicht dumm und schreiben die gesamte Software in C und Assembler.

Grund der Beschwerde: