Performance VS Codestruktur/Codevereinfachung

[himitsu]

Zitat:

Wie der Titel schon sagt geht es darum, in welchem Fall oder bzw. ist es heutzutage überhaupt manchmal noch sinnvoll einen Code zuschreiben,
der etwas "komplizierter" im Aufbau ist, aber dadurch gute Performance gibt, oder eher einen Code, der eine leichte und verständliche Struktur hat.

Ich halte es so:

* im Normalfall "einfach"
* wenn zeitkritischer oder viel zu langsam, dann "schnell", aber möglichst "einfach" (also Beides kombiniert)
* wenn extrem zeitkritisch .... nja, kommt selten vor

Zitat:

denn im letzteren müssen keine Werte kopiert werden.

kommt drauf an, was koppiert werden muß

Zitat:

Delphi-Quellcode:

var
  I, Found1,Found2,Found3 : Integer;
begin
  Found1 := -1; //Auf einen Wert setzen, der 100% nicht im Array ist.
  Found2 := -1;
  Found3 := -1;
  for I := Low(TestArray) to High(TestArray) do
  begin
    if (Found1<>-1) and (Found2<>-1) and (Found3<>-1) then
      Break;
    if TestArray[I] = 5 then
    begin
      Found1 := 5;
      Continue;
    end;
    if TestArray[I] = 50 then
    begin
      Found2 := 5;
      Continue;
    end;
    if TestArray[I] = 9 then
    begin
      Found3 := 5;
      Continue;
    end;
  end;
end;

Continue? -> ELSE

if (Found1<>-1) and (Found2<>-1) and (Found3<>-1) then ... danach, denn davor kann es nicht zutreffen,
bzw. da prüfen, wo die Continue stehen, denn nur da hat sich gerade was geändert

z.B.

Delphi-Quellcode:

for I := Low(TestArray) to High(TestArray) do
begin
  case TestArray[I] of
    5: Found1 := 5;
    50: Found2 := 50; //5;
    9: Found3 := 9; //5;
    else Continue;
  end;
  if (Found1<>-1) and (Found2<>-1) and (Found3<>-1) then
    Break;
end;

Found* sind doch eher Boolean (Wert gesetzt oder nicht).

[Uwe Raabe]

Eigentlich bringst du wohl eher unfreiwillig in deinem Eingangspost schon ein gutes Argument gegen die optimierte Variante: Dein Beispielcode mit Break - Continue liefert nämlich in den Variablen Found1..3 andere Werte als die übersichtlichere Routine mit FindValue. Typischer Copy-Paste-Error halt.

[Phoenix]

Ich sag dazu nur: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

Kurzum: Schon vor 30 Jahren war das Problem da, und damals sagte man: Mach das es tut, dann mach es richtig, dann mach es schnell.

Und ja, natürlich ist es legitim sich heutzutage Gedanken über performance und optimierte Verarbeitung zu machen.
Die Frage ist allerdings, ob es wirklich nötig ist.

Beispiel:
Du lädst diese Daten von einer DB, um sie dann in Deiner Anwendung zu sortieren und zu bearbeiten.
Ist es nicht vielleicht sinnvoller, das filtern und sortieren ggf. auf der DB zu machen? Vermutlich.
Kann die DB das gut? Nein? -> Vielleicht nutzt Du nicht die richtige Art von Datenbank. Kann eine anderen Datenbank das besser? Ja? -> Problem gelöst.

Wenn Du eine spezielle Aufgabe hast ist es es vielleicht die beste Option, diese Aufgabe an Tools zu delegieren, die es a) inzwischen meist für umme gibt und b) für diesen Fall hochspezialisiert sind.

Beispiel Suche: Wer implementiert denn heute noch eine schnelle Suche selber? Hochkomplexe binäre baumstrukturen für Indices, die richtig zu verwalten etc... Heute nimmt man da SolR oder Elasticsearch, pumpt die zu durchsuchenden Daten da rein, ein REST-Call und *wuppdi* sind die Ergebnisse da. Und ja: Man muss ein zusätzliches Softwaresystem installieren und am laufen halten. Und ja: Das kostet im Zweifel auch Hardware. Aber das Ergebnis ist deutlich besser als das, was man selber erreichen könnte (da arbeiten im Zweifel hunderte Spezialisten an komplexester Optimierung), und man bekommt das vor allem inkl. Doku und einer Community die man um Hilfe bitten kann sozusagen frei Haus geliefert.

Stream Processing? Apache Kafka und Konsorten. Logaggregation und Analyse? FluentD, ElasticSearch, Kibana. Verteiltes Caching? Redis.

Es gibt kaum noch Bereiche, die nicht schon durch existierende Lösungen sehr gut abgedeckt sind und sich meist mit wenig Aufwand integrieren lassen.

[Dejan Vu]

Zitat von Phoenix:

Ich sag dazu nur: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

Genau das funktioniert eben nicht (immer). Der Performanceaspekt muss Bestandteil der Business requirements sein, nur dann kann man in seiner Architektur darauf Rücksicht nehmen.

Beispiel: Wir wollen Daten über einen Service an einen externen Provider verschicken. Der Service muss sich zu jedem Datenpaket noch zusätzliche Daten aus der DB holen. Wenn ich das jetzt naiv löse (am besten noch mit tollen Businessobjekten per lazy load), kann ich mir hinterher etwaige Performanceoptimierungen abschminken. Auch ein Cache bringt nicht viel.

Allerdings würde ich innerhalb der Requirements dein Tantra berücksichtigen. Vermutlich ist das auch so gemeint.

Was die Eingangsfrage anbelangt: In seltenen Ausnahmefällen wird man schmutzigen Code schreiben müssen, der einfach nur auf Performance ausgelegt ist. Dieser Code sollte imho dann ausgelagert und explizit als "Mittel zum Zweck" kommentiert werden. Das wird aber nur sehr selten nötig sein.

Tolle Standardlösungen wird man aber auch nicht ständig verwenden können, zumal wir hier nicht direkt von Enterpriselösungen reden, sondern eher von bisserl Code.

Allerdings: Einen optimalen Algorithmus wird es allemal geben.

[himitsu]

Ja, ich weiß ... CASE mit String und Pascal ... nja, was soll's.

Delphi-Quellcode:

case IndexText(TestArray[I], ['5', '50', '9']) of
  0: Found1 := 5;
  1: Found2 := 50;
  2: Found3 := 9;
  else Continue;
end;

Oder besser gleich ein TDictionary<>, statt dem Case.

[mquadrat]

Erst mal immer die Variante nehmen, die besser wartbar ist. Stellt sich diese in der Praxis als zu langsam raus, dann erst optimieren. Das hat folgenden Vorteil: Ist es gar nicht zu langsam, kann man Änderungen viel einfacher einbauen. Schnelleres Coding, weniger Fehler --> alle glücklich. Habe ich vorher eine ultra-schneller, aber auch ultra-komplexe Lösung gebaut, dann wird jede Änderung zur Qual. Langsameres Coding, mehr Fehler --> keiner glücklich.

[NickelM]

Zitat von Uwe Raabe:

Eigentlich bringst du wohl eher unfreiwillig in deinem Eingangspost schon ein gutes Argument gegen die optimierte Variante: Dein Beispielcode mit Break - Continue liefert nämlich in den Variablen Found1..3 andere Werte als die übersichtlichere Routine mit FindValue. Typischer Copy-Paste-Error halt.

Ja stimmt, naja dies wäre spätestens beim Testen des Codes dann aufgefallen. Aber ja stimmt. Hab vergessen das Zuändern.

Zitat von himitsu:

Delphi-Quellcode:

for I := Low(TestArray) to High(TestArray) do
begin
  case TestArray[I] of
    5: Found1 := 5;
    50: Found2 := 50; //5;
    9: Found3 := 9; //5;
    else Continue;
  end;
  if (Found1<>-1) and (Found2<>-1) and (Found3<>-1) then
    Break;
end;

Wenn man Case verwenden kann (falls man nicht auf einen String testen muss) ist diese Variante natürlich auch gut. Naja bei Strings muss man dann auch If...then...else..if...then...else continue; verwenden, was aber klar ist. Werde ich mir mal merken.

Zitat von Sir Rufo:

Es kommt halt immer darauf an.

Hier sehe ich aber auch einen Standard-Fall (sind die Elemente in Menge A in der Menge B enthalten), wo es sich lohnt die eigene Bibliothek um diesen Fall zu erweitern.

Wichtig im Hinblick auf die Performance ist die richtige Art durch die Arrays zu iterieren:

langsam

Delphi-Quellcode:

for a in ValuesA do
  for b in ValuesB do
    if Comparer.Equals( a, b ) then

vs. schnell

Delphi-Quellcode:

for idxA := Low( ValuesA ) to High( ValuesA ) do
  for idxB := Low( ValuesB ) to High( ValuesB ) do
    if Comparer.Equals( ValuesA[idxA], ValuesB[idxB] );

denn im letzteren müssen keine Werte kopiert werden.

Okay, dies stimmt nun auch wieder. In diesem Fall ja. Aber man greift dann sowieso standardmäßig auf den Array eintrag direkt hinzu. Dazu fällt mir was anderes gerade ein.
Wenn ich nen Array von Record durchgehen muss, was wäre dann schneller? Einen Pointer auf den Record vom Array speichern und den Pointer zum lesen benutzen oder eher direkt immer über den Array abfragen?

Delphi-Quellcode:

TestP := @TestArray[I];
if TestP^.I = 5 then
  Result := TestP^.S;

VS.

Delphi-Quellcode:

if TestArray[I].I = 5 then
  Result := TestArray[I].S;

Zitat von Phoenix:

Ich sag dazu nur: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

Kurzum: Schon vor 30 Jahren war das Problem da, und damals sagte man: Mach das es tut, dann mach es richtig, dann mach es schnell.

Und ja, natürlich ist es legitim sich heutzutage Gedanken über performance und optimierte Verarbeitung zu machen.
Die Frage ist allerdings, ob es wirklich nötig ist.

Beispiel:
Du lädst diese Daten von einer DB, um sie dann in Deiner Anwendung zu sortieren und zu bearbeiten.
Ist es nicht vielleicht sinnvoller, das filtern und sortieren ggf. auf der DB zu machen? Vermutlich.
Kann die DB das gut? Nein? -> Vielleicht nutzt Du nicht die richtige Art von Datenbank. Kann eine anderen Datenbank das besser? Ja? -> Problem gelöst.

Wenn Du eine spezielle Aufgabe hast ist es es vielleicht die beste Option, diese Aufgabe an Tools zu delegieren, die es a) inzwischen meist für umme gibt und b) für diesen Fall hochspezialisiert sind.

Beispiel Suche: Wer implementiert denn heute noch eine schnelle Suche selber? Hochkomplexe binäre baumstrukturen für Indices, die richtig zu verwalten etc... Heute nimmt man da SolR oder Elasticsearch, pumpt die zu durchsuchenden Daten da rein, ein REST-Call und *wuppdi* sind die Ergebnisse da. Und ja: Man muss ein zusätzliches Softwaresystem installieren und am laufen halten. Und ja: Das kostet im Zweifel auch Hardware. Aber das Ergebnis ist deutlich besser als das, was man selber erreichen könnte (da arbeiten im Zweifel hunderte Spezialisten an komplexester Optimierung), und man bekommt das vor allem inkl. Doku und einer Community die man um Hilfe bitten kann sozusagen frei Haus geliefert.

Stream Processing? Apache Kafka und Konsorten. Logaggregation und Analyse? FluentD, ElasticSearch, Kibana. Verteiltes Caching? Redis.

Es gibt kaum noch Bereiche, die nicht schon durch existierende Lösungen sehr gut abgedeckt sind und sich meist mit wenig Aufwand integrieren lassen.

Da stimme ich dir auch zu. Es ist logisch, wenn man was komplexes haben will, man lieber Komponenten nihmt, die das können und sich schon viele Leute den Kopf darüber zerbrochen haben.
Ich gehöre zu der Art von Programmierer, die sich halt genau selber über solche Sachen gedanken macht und verstehen will zumindest um groben was besser wäre. Manche Dinge verlangen wiederrum speziales Fachwissen in dem jeweiligen Bereich, womit man besser bedient ist, sich auf Komponenten zuverlassen als selber Hand anzulegen. Es geht mir auch um Fälle, wo es speziel auf die jeweilige Daten vielleicht abgestimmt werden muss. Also ich hab schon öfters nen kleinen Algo geschrieben, auch wenn der recht bescheiden war, der meine Zwecke erfüllt.
Wegen irgendwelche Kleinigkeiten finde ich, muss man keine große Lib verwenden. Und in diesem Fall möchte ich schon wisssen, wie es funktioniert. (Dies trifft halt aber nur kleinen Mengen zu, worum es ja in dieser Diskussion mir ja nicht geht )
Aber wenn ich eine Lib benutze, weil es ein bekanntes Problem ist und es nicht mit der funktioniert, was dann? (Gehen wir auch mal davon aus, dass dies die einzige ist, die nah dran kommt und überhaupt das man in etwa macht, was man will ) Ich kann mir nicht vorstellen, das ein Kunde dann sagt : "Ist egal, dass es lange Dauert, hauptsache funkt."
Dann wäre es sinnvoll, wenn man sich als Programmierer mit anderen zusammen setzt und schaut wo das Problem an der Lib liegt und wie man es lösen kann. Selber schreiben oder Lib selber erweitern, für diesen Zweck. Wäre es dann nicht auch sinnvoll, zuwissen wie diese funktioniert und warum die Leute der Lib das so gemacht haben? Oder denke ich da wieder viel zu weit?
Naja okay, eigentlich kann ich mir die Frage fast selber beantworten...Zu den Leuten von der Lib gehen und sagen "Hi, ehm ja eure Lib macht nicht das was wir wollen. Macht mal." Hab ich recht?

[Sir Rufo]

Ob Pointer oder Array-Zugriff ist eins -> es macht keinen Unterschied.

Ich habe so ein paar TArray Methoden geschrieben und bei 1.000.000 extrem fetten Records im Array dauerte das Durcharbeiten 8ms. Mit for in lag ich bei 20 Sekunden.

Mehr Records konnte ich nicht testen, da der Speicher am Anschlag war