Performance VS Codestruktur/Codevereinfachung

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