Kleiner Optimierungstest

[jbg]

Zitat von Go2EITS:

Da stellt sich für mich die Frage, ob eine Procedure, vorausgesetzt, sie wird oft aufgerufen, die lokalen Variablen, da sie ja jedes mal neu angelegt werden müssen, nicht besser global angelegt werden sollen

Damit wird die Prozedur unflexibler, nicht mehr reentrant (was bei Multithreading eine große Rolle spielt) und des Weiteren unleserlicher, weil man sich erst mal die globalen Variablen zusammensuchen muss, die auch noch an anderer Stelle verändert worden sein könnten. (Unter Linux würdes du mit globalen Variablen sogar ein halb-freies CPU Register [ebx] verlieren, weil nur mittels der GOT [global offset table], die in ebx steht, auf globale Variable zugegriffen werden kann).
[edit]Wobei ebx nur in PIC (Position Independent Code) gesperrt ist, was beim ELF Format bei SharedObjects der Fall ist.[/edit]

Zitat:

Dabei habe ich keine Ahnung, ob die untere Version performancemäßig, wirklich etwas bringt.

Wirklich bringt meines Ermessens nach unnötige Funtionsaufrufe wie:
// Die schlechte Version
for I:=1 to length(String)..
statt
// Die gute Version
s:=String;
for i:=1 to S ...

Der Compiler ist schon so schlau, dass er nur ein einziges Mal Length(String) aufruft.

[Der_Unwissende]

Zitat von Go2EITS:

Wirklich bringt meines Ermessens nach unnötige Funtionsaufrufe wie:

Delphi-Quellcode:

  // Die schlechte Version
  for i := 1 to length(String)..

  // statt
  // Die gute Version

  // denke du meitest eher so etwas
  L := length(String);
  for i := 1 to L ...

Was mein Ihr?

Hier meine ich, dass ein guter Compiler diese Optimierung ohne Probleme selbst vornehmen sollte. Da es sich um eine Schleife mit festen Grenzen handelt, würde es mich sogar sehr wundern, wenn du hier unterschiede in der Umsetzung findest.

Was die Optimierung von Code angeht, so stehe ich dem immer sehr kritisch gegenüber. Es gibt zwar viele Stellen, an denen man den Code etwas perfomanter machen kann, aber es bleibt die Kosten/Nutzen Frage. Die Stellen zu finden und lesbar zu optimieren kostet häufig eine Menge Zeit (die man selten dafür hat).
Und dann? Wieviel Perfomance man wirklich rausholt hängt natürlich stark vom Programm ab. Aber es ist nun einmal so, dass zu 80% seiner Zeit ein Benutzer nur 20% der Funktionalität verwendet. Nur in diesen 20% machen also Optimierungen wirklich Sinn. Das Problem ist, dass dieser häufiger benutzte Teil erstmal gefunden werden muss. Zudem sollte insbesondere dieser Teil fehlerfrei bleiben (was dann gegen einzelne Optimierungen sprechen kann).

Es ist zwar wirklich interessant zu sehen was der Compiler wie umsetzt, aber auch hier gilt, dass die nächste Evolution des Compilers ein wenig besser optimieren wird und vielleicht einzelne eigene Optimierungen entfallen. Hat man leicht lesbare Quellen, hat man alle Vorteile, die das mit sich bringt. Mit einem neuen Compilieren sind die eventuellen perfomance Nachteile dann auch beseitigt... (zur Lesbarkeit gehören dann natürlich auch Prozeduren, auch wenn die einen minimalen Overhead mit sich bringen. Zudem haben sie einen großen Nutzen in Wiederverwendbarkeit)

So, gerade den roten Kasten bekommen, also sorry für die Widerholungen!

[Go2EITS]

@jbg
@unwissende
Danke für die ausführlichen Antworten!

Dann doch Procedure/Funktionen mit lokalen Variablen, damit übersichtlich und besser wiederverwendbar,
der Rest ist Compilersache, der viel optimiert, wie ich in Euren Beiträgen entnehmen kann.
Und dann lege ich wieder ein for i=1 to Lenght(S) an. Damit wird der Code wieder übersichtlicher.

CU
Go2EITS

[Stefan Hueg]

Zu den globalen Variablen gibt es einen Grundsatz den mein GDI-Lehrer mal gesagt hat (studiere Informatik):
"Variablen sollten so nahe wie möglich an/in der Procedur deklariert werden..."

EDIT:
@jbg: Sollte es bei Strings bzw. dyn. Arrays nicht schneller sein (obwohl man dabei aufpassen muss was man mit den Parametern macht) wenn man die Parameter da per Referrenz übergibt, damit keine Kopie des Strings (der ja auch bis zu 2 GB groß sein kann) oder dyn. Arrays lokal angelegt wird?

[jbg]

Zitat von Stefan Hueg:

Sollte es bei Strings bzw. dyn. Arrays nicht schneller sein

Und was meinst du macht const? Übrigens Strings und dyn. Arrays werden immer ByRef übergeben und erst in der Methode kopiert bzw. unique gemacht.

Zitat:

wenn man die Parameter da per Referrenz übergibt

Bei var/out Parameters muss der Compiler trotzdem eine try/finally-Block einbauen und den Referenzzähler erhöhen, was er bei const eben nicht macht, weil da schon gar nicht die Möglichkeit besteht den Parameter zu ändern, weder direkt noch mit Hilfe einer aufgerufenen Funktion.

[Stefan Hueg]

Mea Culpa

Da fällt mir grade eine Frage zum Thema Optimierung ein: Ist es besser

Delphi-Quellcode:

if Length(IrgendEinDynArray) > 0 then
...

oder

Delphi-Quellcode:

if high(IrgendEinDynArray) > -1 then
...

zu schreiben?

[Dax]

Length ist "besser", da High erstens weniger intuitiv ist (High(leeres Array) = -1) und High intern auch nur Length aufruft, aber den Wert noch um 1 verkleinert, bevor es ihn zurückgibt.

[Der_Unwissende]

Zitat von Dax:

High intern auch nur Length aufruft, aber den Wert noch um 1 verkleinert, bevor es ihn zurückgibt.

Nun ja, ganz so stimmt das natürlich nicht. Wenn du die Länge möchtest, dann ist es natürlich sinnvoll, wenn du length verwendest. High = -1 macht schon deswegen keinen Sinn, weil es auch nicht 0 indizierte Arrays gibt (ein String ist z.B. 1 indiziert). Hier würden Low und High entsprechend die korrekte untere bzw obere Grenze liefern.

Delphi-Quellcode:

var x : Array[10..20] of Integer;
begin
  length(x) = 10

  // aber 

  high(x) = 20 (Länge minus eins wäre vielmehr 9)
end;

Ein Vergleich welchen Wert high hat macht i.d.R. keinen Sinn. Ja, auch wenn man vieles auch anders schreiben kann, es ist nicht immer das Gleiche!

[Dax]

Unwissender: Ich bezog mich direkt auf das Beispiel aus dem Post obendrüber, und da gings ja um dynamische Arrays Aber generell hast du Recht, Low() liefert den ersten Index und High() idR den letzten.