Performance VS Codestruktur/Codevereinfachung

[NickelM]

Hallo zusammen,

Ich wollte mal eine allgemeine Diskussionsrunde eröffnen, mit einem Thema das mich schon sehr lange in der Programmierung beschäftigt.
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.
Es bezieht sich größten Teils um Schleifen, die durchgegangen werden müssen, die ziemlich lang sind. Bei kleinen Arrays, ist es mir klar, dass
es bei den heutigen Rechner recht egal ist.
Ich nenne mal ein kleines Beispiel:
Ich habe einen Array mit folgenden Daten: var TestArray : array of Integer = [5,7,8,1,4,9,2,80,50...] Nun will ich bestimmte Zahlen aus diesem Array nur haben. Nehmen wir mal an : 5,50,9 Der Array kann aber halt unterschiedlich groß sein. (Und ich weiß, mann könnte ihn jetzt sortieren, darum geht es mir aber nicht. Sagen wir mal die "Daten", wofür das Beispiel steht, kann man nicht so leicht sortieren.)
Mir würden jetzt 2 Arten einfallen, dies in Code umzusetzen. Die eine wäre mit Sachen wie Break; ,Continue; . Die andere wäre mit einer Prozedur.

Delphi-Quellcode:

//Die Variante mit Break und Continue
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;

Diese Variante würde jetzt sie Schleife durchgehen, bis die 3 Werte gefunden wurden. Es geht halt jetzt auch noch darum, dass die Anzahl von Werten, die gesucht werden sich ändern können.
Die Variante, kann man natürlich in ne "komplexere" Prozedur packen, um einen leichten Aufruf zumachen, aber das Grundprinzip wäre gleich.

Eine recht einfache Code Variante wäre jetzt diese :

Delphi-Quellcode:

function FindValue(aArray : array of Integer; aNeedValue : Integer) : Integer;
var 
  I : Integer; 
begin
  Result := -1;
  for I := Low(aArray) to High(aArray) do
  begin
    if aArray[I] = aNeedValue then
    begin
      Result := aNeedValue;
      Exit;
    end;
  end;
end;

var
  Found1,Found2,Found3 : Integer;
begin
  Found1 := FindValue(TestArray,5);
  Found2 := FindValue(TestArray,50);
  Found3 := FindValue(TestArray,9);
  if (Found1<>-1) and (Found2<>-1) and (Found3<>-1) then
  begin
    //Weitere Ablauf danach
  end;
end;

Mann sieht sofort das bei dieser Variante, der Array natürlich mehrmals durchgegangen wird, aber schon um einiges übersichtlicher ist. (Natürlich kann im Array auch nen Record liegen, wo ein Wert geprüft werden muss und ein andere Wert vom Record benötigt wird. Das Beispiel wollte ich jetzt recht einfach halten)

Jetzt zu den Fragen :
Macht es sinn einen Code in der 1. Variante eher zuschreiben als in der 2. ?
Macht es eigentlich überhaupt heutzutage noch sinn oder solche Code-Strukturen nachzudenken, oder denke ich da nur zu Performance orientiert?
Würde euch noch eine Variante vielleicht einfallen, die ich jetzt nicht bedacht habe, die beides vereint?
Was wäre euch als Programmierer, der an einem Projekt mitarbeitet, wichtiger?

Gruß NickelM

[Der schöne Günther]

Ich will keine Spaßbremse sein, aber das Wichtigste wäre mir eine ordentliche Dokumentation, ganz egal wie die Implementation aussieht. Es muss klar ersichtlich sein dass ich nicht nach "-1" suchen kann da du das als Ersatz für "Nicht gefunden" nimmst. Auch verstehe ich nicht ganz warum du den Wert noch einmal zurückgibst wenn man doch nur den will. Dich interessiert doch nur ob alle drei gefunden wurden. Oder?

Dass der Code leserlich und verständlich ist doch generell wichtiger als vielleicht ein paar Takte zu sparen. Ist es wirklich ein Flaschenhals, erst dann lohnt es sich, auf Geschwindigkeits-Optimierungen zu stürzen.

Dann musst du schauen, wiederverwendbaren Code zu produzieren. Sind es immer fix drei Werte bei denen du wissen willst "Kommt vor? J/N". Warum nicht gleich ein Array machen wo du so viele Werte reinstecken kannst wie du willst?

Ich persönlich würde es so machen:

Delphi-Quellcode:

/// <returns>
///     Gibt an ob alle Elemente in <paramref name="checkFor" />
///      in <paramref name="checkedArray" /> enthalten sind
/// </returns>
/// <param name="checkFor">
///      Elemente können mehrfach vorliegen. Ist zwei mal das Element <c>0</c>
///    enthalten <b>muss</b> <paramref name="checkedArray" /> das Element
///    <c>0</c> zwei mal enthalten, sonst wird <c>False</c> zurückgegeben
/// </param>
function arrayContains(
   const   checkedArray:   TArray<Integer>;
   const   checkFor:      TArray<Integer>
): Boolean;
var
   arrayIterator:      Integer;
   checkForRemaining:   TList<Integer>;
   checkedInteger:      Integer;
begin
   checkForRemaining := TList<Integer>.Create();
   try
      checkForRemaining.AddRange(checkFor);

      for arrayIterator in checkedArray do begin
         for checkedInteger in checkForRemaining do
            if (arrayIterator = checkedInteger) then begin
               checkForRemaining.Remove(checkedInteger);
               Break;
            end;
      end;

      Result := (checkForRemaining.Count = 0);
   finally
      checkForRemaining.Destroy();
   end;
end;

Das ist flexibel (wenn auch auf grade Integer zugeschnitten) und erlaubt auch das Prüfen auf mehrfaches Vorkommen eines Elements.

Delphi-Quellcode:

const
   testArray:   TArray<Integer>   = [4, -12, 0, -1, 99, 0];

   checkFor1:   TArray<Integer>   = [99, 4, 0];
   checkFor2:   TArray<Integer>   = [6, 66, 666];
   checkFor3:   TArray<Integer>   = [0, 0];
   checkFor4:   TArray<Integer>   = [0, 0, 0];
begin
   WriteLn( arrayContains(testArray, checkFor1) );      // True
   WriteLn( arrayContains(testArray, checkFor2) );      // False
   WriteLn( arrayContains(testArray, checkFor3) );      // True
   WriteLn( arrayContains(testArray, checkFor4) );      // False

   readln;
end.

Ich persönlich wäre damit zufrieden. Ist das performant? Nein, wahrscheinlich geht da mehr. Insbesondere wenn es keine Integer sondern Records wären.

[Sherlock]

Die Breaks und Continues sind meiner Menung nach gar nicht nötig, da Du ja abhängig von Found1-3 die Bearbeitung der Schleife beenden könntest, wenn du nicht ein for sondern ein while oder repeat...until verwenden würdest. Dann ist die Schleife genauso performant, und trotzdem besser verständlich.

Oder ist for so viel besser als while?

Sherlock

[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.

[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.

[Mavarik]

Zitat von NickelM:

Macht es eigentlich überhaupt heutzutage noch sinn oder solche Code-Strukturen nachzudenken, oder denke ich da nur zu Performance orientiert?

Man sollte wissen welchen Code der Compiler aus den diversen Anweisung erzeugt.
Dann kann man abwägen, ob a besser ist als b.

Beispiel : For in Schleife.

Wenn ich die Werte ändern möchte, fällt Beispielsweise die "For in" Schleife schon mal weg, weil die werte Readonly sind (bzw. Kopien) sind.

Kann man einfach drauf los programmieren, weil die Rechner heute schnell genug sind? NEIN!

Aber wenn die Optimierung für 5ms 2 Tage dauert... Finger weg - es sei den die Routine soll 200x pro Sekunden aufgerufen werden...

Wenn es läuft sind mir weniger Zeilen Source-Code immer lieber... Also versuche ich so wenig wie möglich neu zu programmieren, sondern eher auf eine vorhandene Routine zurück zu greifen.

Klar wird meine Intervalschachtelung auf ein sortiertes Array schneller sein als erst ein Dictionary zu befüllen... Aber wie schnell schleicht sich ein Fehler ein (Klassiker sind die so genannten succ/pred Probleme der Grenzen).

Mavarik

[Dejan Vu]

Erst den Scope definieren, dann den dafür geeigneten Algorithmus auswählen und dann, wenn es klemmt, optimieren.

[stoxx]

Zitat von NickelM:

Jetzt zu den Fragen :
Macht es sinn einen Code in der 1. Variante eher zuschreiben als in der 2. ?
Macht es eigentlich überhaupt heutzutage noch sinn oder solche Code-Strukturen nachzudenken, oder denke ich da nur zu Performance orientiert?
Würde euch noch eine Variante vielleicht einfallen, die ich jetzt nicht bedacht habe, die beides vereint?
Was wäre euch als Programmierer, der an einem Projekt mitarbeitet, wichtiger?

Gruß NickelM

Ich denke schon, dass es auch heutzutage noch Sinn macht.


Wenn Du irgendwann zu einem definierten Übergabepunkt und einem übersichtlichen Interface kommst und Deine gewünschte Aufgabe einzig und allein in einem abgeschlossenem CodeBereich existiert, dann ist doch alles gut.
Schlimm wäre es nur, wenn es in sogenannten Spagetticode endet, die Variablen überall kreuz und quer über weite Codebereiche verwendet werden .

Allerdings solltest Du die Möglichkeit von Multithread-Lösungen ebenso nicht außer Acht lassen.

[Sailor]

Na ja, es ist wie immer: Es hängt ab. Solange Du im Hobbykeller etwas für Dich zusammenbaust, ist es egal. Du bist derjenige, der mit den Konsequenzen leben muß. Anders ist das im professionellen Umfeld. Dort werden Programme 20, 30, 40 Jahre lang genutzt und unterliegen demgemäß dauernden Änderungen, die dann aber meist nicht mehr der vornehmen muß, der das Original verbrochen hat. Hier gilt der Spruch: The proof of the program is not in its writing, it is in its reading. Von daher kann ich nur dazu raten, den Code so verständlich wie möglich zu halten. Wobei man sich darüber im Klaren sein muß, was das "verständlich" hier bedeutet. Und noch was: Effizienz hängt in erster Linie von der Wahl des Algorithmus ab. Eine noch so raffinierte Implementierung eines Algorithmus mit Zeitkomplexität O(n²) wird einem der Komplexität O(n log n) kaum das Wasser reichen können. Auch die Daten, mit denen das Programm beaufschlagt wird, müssen in die Rechnung eingehen. Bei bis zu 10 Elementen ist ein lineares Feld sicher das effizienteste Mittel der Wahl, der Verwaltungsaufwand ist hier am geringsten. Ein geordnetes Feld mit binärer Suche wäre dagegen geeigneter bei größeren Mengen, die ziemlich konstant sind usw. usw.
Die Quintessenz ist: Problembeschreibung -> Algorithmenwahl -> Lesbare Umsetzung. Und dann optimieren, wenn es klemmen sollte.