Performance VS Codestruktur/Codevereinfachung

[himitsu]

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

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.

[Mavarik]

Zitat:

Zitat von NickelM (Beitrag 1324476)

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

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... :roll:

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:

Zitat von NickelM (Beitrag 1324476)

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? :-D
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.