Naja, eines noch: man sollte wissen wie was wann der Compiler compiliert
D.h. man sollte wissen was die einzelnen Aufruf Konventionen für direkte und indirekte Auswirkungen auf das beste Codedesign haben. Zb. arbeiten wir standardmäßig mit Register Aufrufkonvention. Beachtet man im Design das jede Funktion max. 3 Parameter ordinalen Types hat -> Integer/Pointer und Klassen Methoden max. 2 solcher Parameter, dann ist dies die optimale Vorgehensweise damit der Optimierer schnellen Code erzeugen kann. Man sollte dann auch bedenken das die Anzahl der lokalen Variablen in den Proceduren gering gehalten wird. Auch dies ermöglicht dem Optimierer die bestmögliche Arbeitsweise um mit den vorhandenen Registern jonglieren zu können. Auch deshalb sind nested Proceduren sinnvoll. Denn der Optimeirer optimiert jede Funktion für sich gesehen. Je einfacher und linear strukturiert eine Procedure ist je besser kann der Optimierer seine Arbeit machen. Es gibt also direkte Abhänigkeiten des erzeugten Codes durch den Compiler zum gewählten Design.
In kurz:
- 3 ordinale Paramter maximal für Proceduren
- 2 ordinale Paramter maximal für Methoden (Self ist der 3. unsichtbare Parameter)
- register Aufrufkonvention wenn möglich
- Result immer nur am Ende der Funktion belegen, oder vor einem Exit;
- möglichst wenige lokale unkomplizierte Variablen
- das Aufsplitten komplexer Funktionen auf mehrere weniger komplexe Funktion macht den Code meistens schneller, da der Optimierer besser arbeiten kann (gilt auch für nested Proceduren)
Mit dem Result hier ein Source:
Delphi-Quellcode:
function BadResultUsage: Integer;
var
I: Integer;
begin
Result := 1;
for I := 0 to 1024 do
Result := Result + Result;
end;
function GoodUsage: Integer;
var
I,J: Integer;
begin
J := 1;
for I := 0 to 1024 do
J := J + J;
Result := J;
end;
In komplexeren Sources wird nämlich in BadResultUsage das Resultat im Stack zwischen gespeichert. In GoodUsage geben wir aber dem Optimierer in J die Berechnungsvariable vor, die der Optimierer innerhalb der Loop in ein Register optimieren kann. Erst am Ende der Funktion wird das Resultat belegt, was meistens durch den Optimierer einfach bedeutet das er das optimierte Register J ind Register EAX kopiert. In BadResultUsage wäre dies aber im Stack gespeichert.
Wohlgemerkt obige Beispiele sind zu einfach, das heist der Optimierer kann so wie sie sind beide optimal umsetzen. Würde man aber viel mehr Code drinnenstehen haben tritt diese Regel in Kraft.
Nochwas: man sollte nach Möglichkeit mit Funktionen mit ordinalen Rückgabewerten arbeiten. Proceduren mit Reückgabeparametern bei Referenzen sind ineffizienter.
Delphi-Quellcode:
procedure BadResultProc(var Result: Integer; Data: Integer);
begin
Result := Result + Data;
end;
function GoodResultFunc(PrevResult, Data: Integer): Integer;
begin
Result := PrevResult + Data;
end;
Gruß hagen