AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Performance VS Codestruktur/Codevereinfachung
Thema durchsuchen
Ansicht
Themen-Optionen

Performance VS Codestruktur/Codevereinfachung

Ein Thema von NickelM · begonnen am 15. Dez 2015 · letzter Beitrag vom 20. Dez 2015
Antwort Antwort
Seite 1 von 2  1 2      
NickelM

Registriert seit: 22. Jul 2007
Ort: Carlsberg
445 Beiträge
 
Delphi 2009 Professional
 
#1

Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 09:42
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
Nickel
"Lebe und denke nicht an morgen"
Zitat aus dem gleichnamigen Bollywoodfilm.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.159 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 10:29
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.

Geändert von Der schöne Günther (15. Dez 2015 um 10:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.798 Beiträge
 
Delphi 12 Athens
 
#3

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 10:37
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
Oliver
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 10:57
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#5

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 11:09
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).
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu (15. Dez 2015 um 11:19 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.453 Beiträge
 
Delphi 12 Athens
 
#6

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 11:24
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.640 Beiträge
 
#7

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 11:59
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.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
NickelM

Registriert seit: 22. Jul 2007
Ort: Carlsberg
445 Beiträge
 
Delphi 2009 Professional
 
#8

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 12:29
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.

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.

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;
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?
Nickel
"Lebe und denke nicht an morgen"
Zitat aus dem gleichnamigen Bollywoodfilm.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#9

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 12:41
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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#10

AW: Performance VS Codestruktur/Codevereinfachung

  Alt 15. Dez 2015, 20:54
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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:30 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz