Set- und Getterfunktionen verwenden oder nicht?

[Nexus]

NewSoftzzz schrieb:

Zeig mir mal bitte einen bisher geposteten sinnlosen Anwendungsfall / Gegenbeweis, der alle Bedingungen erfüllt?

Meine Güte, muss ich mich denn wirklich ständig wiederholen? Lies mal meine Beiträge!

Deine Aussage:

NewSoftzzz schrieb:

Ich meinte nur generell, jede Funktion, die eine std::string Referenz als Parameter hat, sollte man mit nem statischen std::string aufrufen.

Meine Antwort (sei Function() eine Funktion mit const std::string& als Parameter). Der folgende Fall wird von deiner Aussage eingeschlossen.

Nexus schrieb:

static std::string String; 
String = OtherString; // OtherString ist nicht-statischer std::string 
Function(String); // Funktion muss aber mit statischem String aufgerufen werden

So, und jetzt überleg bitte, bevor du wieder postest!

[[Ghost]]

@NewSoftzzz,
Ruhig Blut, es will dich niemand töten

NewSoftzzz schrieb:

WTF? Es ist doch scheiß egal, warum die Methode einen "const std::string&" Parameter hat, sie HAT ihn einfach. PUNKT.

Nein, dass stimmt eben nicht ganz. Wenn man über Performance anfängt zu reden, muss man grössere Bereiche anschauen. Du kannst nicht einfach eine Funktion aus ihrem Kontext reissen, sonst macht die Performance-Überlegung keinen Sinn mehr.

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Deshalb sollten Performance-Überlegungen immer in einem Kontext stehen. Es ist völlig unsinnig, wenn du anfängst Bereiche zu optimieren, welche gar nicht ins Gewicht fallen. Das ist eine Verschwendung Zeit und es hindert zudem noch die Leserlichkeit.

NewSoftzzz schrieb:

JEDER, aber auch wirklich JEDER bisherige "sinnlose Anwendungsfall" hat den Bedingungen des Dogmas nicht entsprochen. Aber die muss ich anscheinend in jedem Post wiederholen:

Wo ist Volkard, wenn man ihn braucht ...

[NewSoftzzz]

[Ghost] schrieb:

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Nun, zugegebenermaßen, eine Stelle die über die komplette Laufzeit nur EIN einziges mal aufgerufen wird, lohnt nicht. Aber ab 2 mal dann schon.

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

mfg, René~

[NewSoftzzz]

Nexus schrieb:

Meine Antwort (sei Function() eine Funktion mit const std::string& als Parameter). Der folgende Fall wird von deiner Aussage eingeschlossen.

Nexus schrieb:

static std::string String; 
String = OtherString; // OtherString ist nicht-statischer std::string 
Function(String); // Funktion muss aber mit statischem String aufgerufen werden

So, und jetzt überleg bitte, bevor du wieder postest!

Und wie genau steht OtherString jetzt zur Compilezeit fest? Da kann ich nur jemanden quoten:
So, und jetzt überleg bitte, bevor du wieder postest!

Wie kann man Programmierer werden, wenn man nicht mal 5 einfache Bedingungen anwenden kann...

mfg, René~

[loks]

NewSoftzzz schrieb:

[Ghost] schrieb:

Wie es Nexus gesagt hatte, wenn beim Start des Programmes eine Datei einmal geladen wird und dies über eine Funktion geschieht, welche einen std::string erwartet, dann wäre es völliger Unsinn, einen static const std::string zu nehmen, denn du hast dadurch gar keinen Vorteil. Im Gegenteil, die Leserlichkeit geht dadurch verloren. Du verkomplizierst deinen Code unnötig.

Nun, zugegebenermaßen, eine Stelle die über die komplette Laufzeit nur EIN einziges mal aufgerufen wird, lohnt nicht. Aber ab 2 mal dann schon.

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

mfg, René~

Google mal die Bedeutung von folgendem Satz:

"Premature optimizing is the root of all evil"

Und ja, das was Du argumentierst fällt unter diese Regel.

[NewSoftzzz]

loks schrieb:

"Premature optimizing is the root of all evil"

Und ja, das was Du argumentierst fällt unter diese Regel.

Nope, bei dem Satz geht es normalerweise um 5% Leistungsverbesserung bei Verschlechterung der Wartbarkeit.

Bei meinem Dogma geht es um 1640% Leistungsverbesserung ohne Verschlechterung der Wartbarkeit.

mfg, René~

[[Ghost]]

NewSoftzzz schrieb:

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

Gut, hier kann ich nun zumindest sagen, dass es einen Vorteil hat. Aber ist der wirklich so wichtig, dass ich den streng nach Dogma immer anwenden sollte? Ich denke eher nicht. Ich programmiere lieber zuerst so, dass man es einfach lesen kann. Zuerst auf die Einfachheit/Lesbarkeit schauen, meinen Code verunstalten kann ich später immer noch.

Vor allem läufst du dann Gefahr, dass du plötzlich überall per static const std::string eine Funktion aufrusft und daher grundsätzlich einfach ein char const* gereicht hätte. Und du merkst es nicht einmal

Dogmen sind immer eine gefährliche Sache. Nimm lieber Richtlinien und setze sie hier so fest:
Wenn eine Funktion oft in einem zeitkritischen Bereich aufgerufen wird, einen std::string const& als Parameter erwartet und man ein Literal übergeben möchte, dann sollte man einen static const std::string verwenden.

[NewSoftzzz]

[Ghost] schrieb:

Wenn eine Funktion oft in einem zeitkritischen Bereich aufgerufen wird, einen std::string const& als Parameter erwartet und man ein Literal übergeben möchte, dann sollte man einen static const std::string verwenden.

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

[Ghost] schrieb:

Aber ist der wirklich so wichtig, dass ich den streng nach Dogma immer anwenden sollte? Ich denke eher nicht. Ich programmiere lieber zuerst so, dass man es einfach lesen kann. Zuerst auf die Einfachheit/Lesbarkeit schauen, meinen Code verunstalten kann ich später immer noch.

Es geht da eigentlich darum, es sich einfach anzugewöhnen. Aber ich weiß gar nicht was ihr alle habt, für mich senkt der seperate String nicht ein bisschen die Lesbarkeit, es ist doch sofort klar, dass das zusammengehört... (notfalls davor und dahinter eine leere Zeile)

[Ghost] schrieb:

Vor allem läufst du dann Gefahr, dass du plötzlich überall per static const std::string eine Funktion aufrusft und daher grundsätzlich einfach ein char const* gereicht hätte. Und du merkst es nicht einmal

Wie gesagt, die Methode ist nicht veränderbar oder eine Überladung mit "const char*" nicht möglich (oder sinnlos, wenn man dann eh wieder einen std::string erzeugen müsste)...

mfg, René~

[kauf dir ne ps3]

NewSoftzzz schrieb:

Benchmark fertig:

#include <sys/time.h>
struct timeval tv;
int myint;
void benchmark(const std::string& input)
{
   myint += input.size();
}

int main()
{
   gettimeofday(&tv, NULL);
   uint64_t start = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   myint = 0;
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark("This is for all the nonbelievers out there, who think that they shouldn't follow this rule.");
   gettimeofday(&tv, NULL);
   uint64_t end = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   std::cout << myint << ": " << (end - start) << std::endl;

   gettimeofday(&tv, NULL);
   start = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   myint = 0;
   static const std::string messageToNonbelievers = "This is for all the nonbelievers out there, who think that they shouldn't follow this rule.";
   for(uint64_t i=0; i< 100 * 1000 * 1000; i++) benchmark(messageToNonbelievers);
   gettimeofday(&tv, NULL);
   end = tv.tv_sec*1000 + (tv.tv_usec / 1000);
   std::cout << myint << ": " << (end - start) << std::endl;
}

Ergebnis:
510065408: 12735
510065408: 775

Faktor 16,4 !!!

lern coden

[Athar]

[Ghost] schrieb:

NewSoftzzz schrieb:

Nehmen wir die Bedingung halt noch dazu: "Der Aufruf muss mindestens 2 mal erfolgen".

Gut, hier kann ich nun zumindest sagen, dass es einen Vorteil hat.

Meinst du das ernst...? Eine Faustregel, die man immer anwenden kann/sollte und die ich auch schon erwähnt hatte, ist: wenn der Zeitaufwand für die Optimierung die Summe der Laufzeiteinsparungen aller jemals erwarteten Programmdurchläufe übersteigt, lohnt sich die Optimierung mit großer Sicherheit nicht.
Und darf ich daran erinnern, dass auch mit der Kopiervariante es immer noch fast 10 Millionen Stringkonstruktionen pro Sekunde sind?
Dass es in diesem speziellen Fall bei dem Server Sinn machen kann, sofern man die Klasse selbst nicht ändern kann, bezweifelt ja niemand. Wer ähnliches aber etwa für einen konstanten Dateinamen macht, ist mit beiden Beinen ins "premature optimization"-Näpfchen getreten.

kauf dir ne ps3 schrieb:

lern coden

Das kannst du dir echt sparen, wenn du keine Verbesserungvorschläge nennst.

[[Ghost]]

NewSoftzzz schrieb:

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

Es geht ja auch darum, keine Dogmen mehr anzuwenden. Dogmen sind schlecht, da man dadurch in ein viel zu enges Denkmuster gezwungen wird.
Und nein, es ist nicht Dummheit es nicht so zu machen, sondern man kann sich eben auch überlegen, ob eine Veränderung der Schnittstelle Sinn machen würde oder vielleicht ein komplettes Refactoring des Bereichs. Wenn man eben in Dogmen denkt, denkt man an solche anderen Möglichkeiten gar nicht mehr. Deshalb habe ich dies auch nicht als ein Dogma hingeschrieben, sondern als eine Richtlinie.

NewSoftzzz schrieb:

Es geht da eigentlich darum, es sich einfach anzugewöhnen. Aber ich weiß gar nicht was ihr alle habt, für mich senkt der seperate String nicht ein bisschen die Lesbarkeit, es ist doch sofort klar, dass das zusammengehört... (notfalls davor und dahinter eine leere Zeile)

void foo()
{
  static std::string const text01 = "hello";
  bar(text01);

  static std::string const text02 = "world";
  bat(text02);

  static std::string const text03 = "my";
  bar(text03);

  static std::string const text04 = "what";
  bar(text04);
}

// gegenüber

void foo()
{
  bar("hello");
  bar("world");
  bar("my");
  bar("what");
}

Du willst mir sagen, dass du beides gleich leserlich findest? Ehm, gut ... wenn du meinst ... ich bin da anderer Meinung ...

NewSoftzzz schrieb:

Wie gesagt, die Methode ist nicht veränderbar oder eine Überladung mit "const char*" nicht möglich (oder sinnlos, wenn man dann eh wieder einen std::string erzeugen müsste)...

Mir ist es ein wenig ein Rätsel, dass du deine eigene Methode nicht verändern kannst. Wenn du sagen würdest, dass du einen std::string in der Funktion brauchst, wäre bereits schon was anderes
Und eine Überladung hätte ich mir dann eher so vorgestellt (in die andere Richtung):

void foo(char const* str)
{
  // ...
}

void foo(std::string const& str)
{
  foo(str.c_str());
}

Allerdings wollte ich mit der Aussage jetzt nicht unbedingt auf diese spezielle Funktion hinaus. Ich meinte es viel allgemeiner, wenn du dich so streng an dein Dogma hälst.

@Athar,
Jap, mein ich ernst. Es ist ein Vorteil, du nennst eine Menge an zusätzlicher Negativpunkten, deshalb komme ich ja auch in der Summe der Punkte zu einem negativen Bescheid für diese Anwendung. Es hat einen Vorteil und x Nachteile

[Nexus]

NewSoftzzz schrieb:

Und wie genau steht OtherString jetzt zur Compilezeit fest? Da kann ich nur jemanden quoten:
So, und jetzt überleg bitte, bevor du wieder postest!

Wo genau in dem Zitat hast du etwas von Compilezeit erwähnt? Und überhaupt, was bringen solche Regeln? Man sollte je nach Kontext seinen Verstand einsetzen und nicht einfach blind static const hinschreiben.

NewSoftzzz schrieb:

Bei der Formulierung ist es kein Dogma mehr, dann ist es schon Dummheit es nicht so zu machen.

Was wirklich dumm ist, sind fixe Prinzipien, die man sich einmal setzt, über die man nie mehr nachdenkt und die einen deswegen zu schlechterem Code zwingen. Die Tatsache, dass du den Begriff "Dogma" derart verharmlost, ist bedenklich.

[kauf dir ne ps3]

Athar schrieb:

kauf dir ne ps3 schrieb:

lern coden

Das kannst du dir echt sparen, wenn du keine Verbesserungvorschläge nennst.

name == Verbesserungvorschlag

[l'abra d'or]

NewSoftzzz schrieb:

Wer jetzt noch widerspricht, bitte Nachteile nennen oder Gegenteil beweisen.

Ich empfinde es beispielsweise als Nachteil, wenn ich eine Funktion nicht sehr oft aufrufe, dass da immer ein statischer std::string im RAM rumgeistert, der nur äußerst selten benötigt wird, nur um genau dann etwas minimal schneller zu sein.
Was sicherlich nett sein kann, ist dass der std::string auch als const deklariert ist und somit in einem Read-Only-Bereich im Speicher liegt, das kann schon nochmal schneller werden.

Ich muss aber auch sagen, dass ich selber noch keine wirklich zeitkritischen Programme entwerfen musste. Ich freu mich, wenn das Programm-Design mir (und anderen) gefällt, wenn ich neue Sachen lerne und umsetzen darf und dabei ein schönes Programm noch schneller wird.

Aber aus dieser möglichen minimalen Verbesserung der Laufzeit in einem möglicherweise vernachlässigbaren Teil der Gesamtlaufzeit eine Fixe Regel zu machen finde ich übertrieben. Deine Angabe von 1600% mehr Speed greift nur, wenn ich tatsächlich im Programm nichts anderes mache als jeden mir vom OS zur Verfügung gestellten Prozessortakt mit std::strings an Funktionen übergeben verbringe. Und das ist eine Annahme, die ich mich ehrlich gesagt nie trauen würde auszusprechen.

Im übrigen hätte ich dein Problem nicht durch lauter im Programm verteilte static-strings gelöst. Wenn du das in ner Funktion machst, und den selben String in einem anderen Teil - sprich Scope - auch ausgeben willst, musst du den nochmal als static ablegen.
Ein Singleton, der alle Strings fasst und dem du mit nem Enum oder direkten Funktionsaufrufen die Strings entlocken kannst, fände ich angenehmer zu bedienen. Bei Rechtschreibkorrekturen oder Übersetzungen hast du auch eine zentrale Anlaufstelle, was die Suchzeit verkürzt.
Weiterer Vorteil: Ich kann bei Programmstart den Singleton (und damit alle Strings) initialisieren. Bei der Version mit in Funktionen verteilten static strings werden diese erst beim ersten Aufruf initialisiert, was genau da wieder etwas länger dauert. Unter der Annahme, dass dein Server eh durchgehend läuft, wird auch der anfangs höhere Speicherverbauch durch noch nicht genutzte Strings wieder eliminiert.
Dieses Konzept weitergedacht, führt dazu, dass jedes Level sicher eigene Messages an den Player schicken wird, manche Sachen (wie Warnungen, allgemeine Anreden, usw.) ändern sich nicht. Also geben wir dem "MessageProvider" verschiedene "MessageBackends" für verschiedene Aufgaben. Manche statisch, manche ändern sich je nach geladenem Level/teilnehmenden Charakteren/....

So haben wir die static const std::string-Deklarationen aus dem Code verbannt und noch zusätzliche Flexibilität gewonnen!

[NewSoftzzz]

Nexus schrieb:

Wo genau in dem Zitat hast du etwas von Compilezeit erwähnt?

4 mal wörtlich und dann noch mehrmals sinngemäß (ca. in 10 VERSCHIEDENEN Posts hab ich das erwähnt)..
Soll ich Zitate raussuchen, um dich noch weiter zu blamieren?

l'abra d'or schrieb:

Ich empfinde es beispielsweise als Nachteil, wenn ich eine Funktion nicht sehr oft aufrufe, dass da immer ein statischer std::string im RAM rumgeistert, der nur äußerst selten benötigt wird, nur um genau dann etwas minimal schneller zu sein.

Wenn ich ein Programm ausführe, wird die Executable in den RAM geladen. Somit ist auch ein c-string-literal ständig im RAM... Es gibt also KEINEN Speichernachteil (wenn es den geben würde, hätte ich das Dogma niemals aufgestellt).

l'abra d'or schrieb:

Ein Singleton, der alle Strings fasst

Das ist auch ein static const string, nur anders verpackt. An sowas hab ich natürlich auch gedacht und passt hervorragend in das Dogma rein.

Athar schrieb:

Eine Faustregel, die man immer anwenden kann/sollte und die ich auch schon erwähnt hatte, ist: wenn der Zeitaufwand für die Optimierung die Summe der Laufzeiteinsparungen aller jemals erwarteten Programmdurchläufe übersteigt, lohnt sich die Optimierung mit großer Sicherheit nicht.

Der Regel stimme ich zu 100% zu. Ich brauche für die zusätzliche Zeile ca. 10 Sekunden, die ich nur in dem Benchmark schon wieder rausgeholt habe. Widerspricht dem Dogma also auch nicht

[Ghost] schrieb:

Du willst mir sagen, dass du beides gleich leserlich findest? Ehm, gut ... wenn du meinst ... ich bin da anderer Meinung ...

Wenn du die Text1-4 nennst, dann garantiert nicht. Ich hab aber auch schon 2 mal geposted, dass der Variablenname am besten eine kurze Zusammenfassung des Textes sein soll.

Nexus schrieb:

Die Tatsache, dass du den Begriff "Dogma" derart verharmlost, ist bedenklich.

Das ist Selbstironie. Natürlich sollte niemand sein Gehirn ausschalten und sobald jemand eine Ausnahme der Regel findet (eine Ausnahme wären Codestellen, die nur 1 mal während der kompletten Runtime ausgeführt werden), darf er die auch gerne posten...

mfg, René~

[tntnet]

theliquidwave schrieb:

Hui.
Erstmal alles verstehen
Ich muss mich morgen dann mal genauer mit der std::string-Klasse befassen. Ich dachte da wohl immer komplett in die falsche Richtung

@ tntnet: Also sollte der Prototyp so:

inline const CClass *CClassManager::getClass(const char *pszName)

oder so:

inline CClass *CClassManager::getClass(const char *pszName) const

aussehen? Ich habe beides schon des öfteren gesehen und beides funktioniert.
Wo ist der Unterschied und was ist in diesem Fall richtig?

Gruß

Ich würde es am ehesten so schreiben:

inline const CClass &CClassManager::getClass(const char *pszName) const

. Zur Not auch so:

inline const CClass *CClassManager::getClass(const char *pszName) const

. Ich vermeide halt Zeiger. Gerade wenn ich garantiere, dass ich wirklich eine Klasse zurück gebe und keinen Null-Zeiger, dann lieber als Referenz.

Das const hinten sagt, dass die Methode den Zustand der Klasse nicht verändert. Das const vorne sagt, dass Du das, was du zurück bekommst, nicht ändern darfst. Es kommt natürlich auf den Anwendungsfall an. Ich weiß nicht so recht, was Du erreichen willst. Wenn es eine Factory-Methode oder ein Sigleton sein soll, dann eventuell auch ohne const am Rückgabewert.

Dass beides funktioniert bedeutet nicht gleich, dass es elegant ist. Ich kann mit syntaktisch korrekten Programmen sehr viel Unsinn verzapfen. Im Prinzip ist das const nie wirklich notwendig. Es hilft nur, saubere Schnittstellen zu definieren.

[[Ghost]]

NewSoftzzz schrieb:

Wenn ich ein Programm ausführe, wird die Executable in den RAM geladen. Somit ist auch ein c-string-literal ständig im RAM... Es gibt also KEINEN Speichernachteil (wenn es den geben würde, hätte ich das Dogma niemals aufgestellt).

Dir ist aber schon klar, dass:
a) Ein std::string Objekt mehr Speicher verbrauchen wird, als ein String-Literal?
b) Das String-Literal auch im static Bereich liegen wird, zusätzlich zum std::string const Objekt?

Somit hast du definitiv einen Speichernachteil, welcher ständig vorhanden ist. Auch wenn ich diesen nicht wirklich als Argument aufführen würde, genauso wie ich den zusätzlichen Aufwand zur Erstellung eines temporären std::string Objekt ignoriere, weil dieser Aufwand in den meisten Fällen völlig unwichtig ist.

NewSoftzzz schrieb:

Wenn du die Text1-4 nennst, dann garantiert nicht. Ich hab aber auch schon 2 mal geposted, dass der Variablenname am besten eine kurze Zusammenfassung des Textes sein soll.

Gut, kann sein, dass du dies gesagt hast, ich finde es trotzdem noch unlesbar. Und zwar in den beiden folgenden Formen:

void foo()
{
  static std::string const hello = "hello";
  bar(hello);

  static std::string const world = "world";
  bar(world);

  static std::string const my = "my";
  bar(my);

  static std::string const what = "what";
  bar(what);
}

// oder

void foo()
{
  static std::string const hello = "hello";
  static std::string const world = "world";
  static std::string const my = "my";
  static std::string const what = "what";

  bar(hello);
  bar(world);
  bar(my);
  bar(what);
}

// gegenüber

void foo()
{
  bar("hello");
  bar("world");
  bar("my");
  bar("what");
}

Es ist schlicht und einfach nicht intuitiv und führt zu einer Indirektion beim Lesen. Man fragt sich regelrecht: Was zum Geier soll das?

Aber wie gesagt, ich kann nicht viel dagegen unternehmen, wenn du das lesbar findest und du kannst nicht viel dagegen unternehmen, dass ich dies unlesbar empfinde.
Du wirst aber wohl zugeben müssen, dass die Version ohne static const Objekte auch lesbar ist? Und wie man hier sieht, ist es für viele lesbar. Man sollte schliesslich Code nicht so schreiben, dass man nur selbst den Code lesen kann, sondern auch andere.

Da kommt halt schon die Frage auf:
Wieso willst du diesen unnötigen Performance Vorteil unbedingt nutzen? Ich meine, wenn du wirklich so auf Performance bedacht bist und das an jedem Ort, egal ob es ins Gewicht fällt oder nicht, dann kannst du gleich C++ in die Tonne schmeissen und wieder mit C arbeiten oder am besten gleich mit Assembler

Dieser Performance "Verlust" ist in 99% der Fälle locker zu verkraften, also wieso vermeiden?

Grüssli

[[Ghost] Busted]

Off-Topic:
... da hat mich doch tatsächlich die Macht der Gewohnheit überlistet, verdammtes 'Grüssli' :p

[Nexus]

NewSoftzzz schrieb:

4 mal wörtlich und dann noch mehrmals sinngemäß (ca. in 10 VERSCHIEDENEN Posts hab ich das erwähnt)..
Soll ich Zitate raussuchen, um dich noch weiter zu blamieren?

Ich habe mich extra auf die eine Aussage beschränkt, weil ich zuerst dachte, dass es sich um einen unüberlegten, schnell hingeschriebenen Satz handelte. Wäre ja auch kein Problem gewesen. Aber statt das Ganze zu relativieren und einen offensichtlichen Fehler einzugestehen beharrst du weiterhin darauf, dass sowas wörtlich und immer gilt.

NewSoftzzz schrieb:

Natürlich sollte niemand sein Gehirn ausschalten

Genau das propagieren Dogmen aber, sonst wären sie Richtlinien oder Faustregeln.

Wie dem auch sei – ich denke, dir ist klar, worauf ich hinauswollte. Wenn du meine Argumente (mit welchen ich ja im Gegensatz zu dir nicht allein stehe) nicht nachvollziehen kannst oder willst, okay. Du könntest in diesem Thread jedoch einiges lernen, wenn du nicht derart in deinen Prinzipien versessen wärst. Merke dir einfach für zukünftige Diskussionen, dass man wenigstens versuchen sollte, auf die Argumente anderer einzugehen. Ich persönlich versuche das auch, und wenn mir das nicht gelingt, bin ich froh um freundliche Hinweise.

[loks]

NewSoftzzz schrieb:

loks schrieb:

"Premature optimizing is the root of all evil"

Und ja, das was Du argumentierst fällt unter diese Regel.

Nope, bei dem Satz geht es normalerweise um 5% Leistungsverbesserung bei Verschlechterung der Wartbarkeit.

Bei meinem Dogma geht es um 1640% Leistungsverbesserung ohne Verschlechterung der Wartbarkeit.

mfg, René~

Du hast Deine Hasuaufgaben nicht gemacht, denn Du hast offensichtlich _nicht_ nachgelesen was premature optimizing ist, denn diese hat absolut nix mit solchen Zahlen zu tuen.

Richtiges Optimieren geht so:

1. Schreib das Programm ohne solche "superoptimierungen" per Dogma.
2. Benutz einen Profiler um das Laufzeitverhalten zu messen
3. Analysier die Funktionen die die meiste Rechenzeit im Profiler belegt haben und optimiert diese und nur diese gezielt.
4. Benutz den Profiler erneut und vergleiche ob die Optimierungen tatsächlich etwas gebracht haben.

Dann, und NUR dann hast Du sinnvoll optimiert.

Auch dazu gibt es eine Merkregel: First make it run, than make it fast.

PUnktuelle Microoptimierungen neigen dazu das sie auf das Gesamtprojekt keine relevante Performance-Auswirkung haben.