postincrement vs preincrement
-
Präinkrement ist immer optimal, Postinkrement kann (muß aber nicht) etwas schlechter sein.
-
ThaRealMatix schrieb:
gibts irgendwie ne Faustregel mit der an es sich merken kann? An sich ist doch bei dem hoczählen kein Unterschied ausser bei der direkten Ausgabe, oder?
Ich würde folgende Faustregel verwenden:
Sofern es nicht bei der Lesbarkeit entscheidende Nachteile gibt, sollte man Preincrement vorziehen. Auch wenn es bei den eingebauten Datentypen eigentlich egal ist zeigt die Erfahrung das der Mensch ein Gewohnheitstier ist. Wenn man es einheitlich durchzieht vergißt man es auch nicht so schnell.
Erklärung:
Beim Preincrement wird das Objekt direkt erhöht und zurückgegeben.
Beim Postincrement wird der alte Stand gemerkt (=> temporäre Variable), dann das Objekt erhöht und die temporäre Variable zurückgeliefert.Um so kleiner ein Objekt umso unproblematischer ist die Frage nach Post-/Preincrement. Aber bei komplexen Objekten kann eine Kopie bemerkbar sein (grade in einer Schleife).
Sofern man bekannte Performancebremsen umgehen kann ohne den Lesefluß stark zu beeinflussen, ziehe ich immer die optimalere vor. Das hat nichts mit vorzeitiger Optimierung zu tun, sondern mit Vermeidung unnötiger Probleme.
cu André
-
Bin mal gespannt, ob ich jemals in meinem Leben auf einen Fall stoßen werde, in dem ++x statt x++ den entscheidenden Performance Vorteil bringt und nix anderes viel mehr.
-
yyy schrieb:
Bin mal gespannt, ob ich jemals in meinem Leben auf einen Fall stoßen werde, in dem ++x statt x++ den entscheidenden Performance Vorteil bringt und nix anderes viel mehr.
Bei integralen Datentypen wird es in der Regel auch wegoptimiert, bei eigenen Zahlenklassen (z.B. für sehr große Zahlen) kann es aber durchaus merkbare Unterschiede machen wenn es in Schleifen passiert... In der Regel wird das aber nicht der Flaschenhals sein, nur wozu bitte eine mögliche Bremse einbauen wenn es nun wirklich keinen wesentlichen Tipaufwand bedeutet? Es ist ja keine Optimierung in dem Sinne das man ganze Codeteile austauschen muss.
cu André
-
ich pers mach es so
- wenn es nur ein hoch- / runter zaehlen ist, pre..
- alles andere, post..
-
Mr Evil schrieb:
ich pers mach es so
- wenn es nur ein hoch- / runter zaehlen ist, pre..
- alles andere, post..Ich machs genau andersrum: grundsaetzlich eigentlich preincrement, wenn ich aber tatsaechlich den alten Wert noch weiterverwursten muss das postinkrement. Und selbst das kann man haeufig umgehen.
-
yyy schrieb:
Bin mal gespannt, ob ich jemals in meinem Leben auf einen Fall stoßen werde, in dem ++x statt x++ den entscheidenden Performance Vorteil bringt und nix anderes viel mehr.
Der entscheidende Performance Vorteil eines Programms setzt sich meisten aus der Summe vieler kleiner Performancevorteile zusammen die einzeln für sich betrachtet eher egal wären...
-
oks schrieb:
yyy schrieb:
Bin mal gespannt, ob ich jemals in meinem Leben auf einen Fall stoßen werde, in dem ++x statt x++ den entscheidenden Performance Vorteil bringt und nix anderes viel mehr.
Der entscheidende Performance Vorteil eines Programms setzt sich meisten aus der Summe vieler kleiner Performancevorteile zusammen die einzeln für sich betrachtet eher egal wären...
Nicht wenn der zugrundeliegende Algorithmus eine miserable Performance hat. In dem Fall bringen auch kleine Verbesserungen an vielen Stellen nichts. NIchtsdestotrotz gehoert dieses Thema hier weniger in den Bereich Optimierung als in den Bereich "unnoetigen Overhead von vornherein vermeiden", aehnlich wie das Thema "call by value vs. call by const reference". Bei beidem handelt es sich um Vermeidung von unnoetigen Kopien.
-
oks schrieb:
yyy schrieb:
Bin mal gespannt, ob ich jemals in meinem Leben auf einen Fall stoßen werde, in dem ++x statt x++ den entscheidenden Performance Vorteil bringt und nix anderes viel mehr.
Der entscheidende Performance Vorteil eines Programms setzt sich meisten aus der Summe vieler kleiner Performancevorteile zusammen die einzeln für sich betrachtet eher egal wären...
Hast du schon mal ein Programm merklich optimiert, indem du viele kleine Stellen verbessert hast?
Alles was ich optimiert hab war immer O(n) -> O(log(n)) oder ähnliches. Und sowas geht nicht, indem man kleine Stellen optimert, sondern eine andere Lösung für das Problem sucht.
-
Warum aber muss man es dann extra "falsch" machen? Es ist doch die selbe Arbeit vom Schreibaufwand her. Es gibt vielleicht nicht viel her an Performance und dann mach ich es so das es auf jeden Fall weniger bringt bei gleichem Arbeitsaufwand.
Komische Einstellung.
c++
++cLässt sich irgendwie gleich tippen, auch ohne Performanceverlust durch die Fingerarithmetik.
Was da passiert muss man aber trotzdem verstehen, gerade bei Mehrfachzuweisungen.