Performaceschädlich?
-
Ja, mal so mal so ...
-
premature optimization is the root of all evil
Solche Mikrooptimierungen schaden meist mehr als sie nützen. Zuerst sollte man gut lesbaren Code erzeugen (was in der Regel auch heißt das man Funktionsgrößen wählt die man sinnvoll überblicken kann, und möglichst "Eine Funktion für eine Aufgabe" erfüllen).
Sauberer Code kann sogar (trotz minimalen Overheads wegen der Funktionsaufrufe) effektiv schneller sein, da man leichter Fehler, Redundanzen etc. sieht und korrigiert.
Erst wenn man wirklich Probleme mit der Performance feststellt, sollte man mittels eines Profilers die Problemstelle ermitteln, und diese optimieren (Ein Profiler deckt zwar nicht jeden Anwendungsfall perfekt ab, aber man selbst wird in mindestens 90% an der falschen Stelle optimieren).
-
knivil schrieb:
Ja, mal so mal so ...
Jopp.
Man könnte auch sagen: das kommt drauf an.
-
Oder je nach dem
-
Bei einer pass-by-reference Argumentenübergabe ist das also schnuppe?
-
Noob_Der_Ersten_Stunde schrieb:
Bei einer pass-by-reference Argumentenübergabe ist das also schnuppe?
Jein und du hast nicht verstanden, was man dir sagen wollte.
-
Das Problem ist: Inlining und Optimierungen sind stark Compilerabhängig. Deswegen bringt mein sein Programm erst mal ordentlich zum laufen, schön übersichtlich. Und hinterher optimiert man, wenn es denn sein muss.
-
meistens macht es überhaupt keinen Unterschied. Und wie immer wird auf solche Kleinigkeiten geachtet während die großen Klopper unbeachtet die Performance runter nagen können
-
Schenkt man dem Eröffnungspost glauben, dürfte in diesem Fall eh keine Hoffnung bestehen, durch derlei Optimierungen zum Erfolg zu gelangen.
Es ist dort nämlich von vielen komplexen Operationen die Rede. Und wenn die Operationen auch nur annähernd komplex (oder einfach nicht komplett primitiv) sind, dürfte die Funktion selbst ein Vielfaches dessen was der Aufruf ausmacht an Zeit verbrauchen.
-
asc schrieb:
premature optimization is the root of all evil
Solche Mikrooptimierungen schaden meist mehr als sie nützen. Zuerst sollte man gut lesbaren Code erzeugen (was in der Regel auch heißt das man Funktionsgrößen wählt die man sinnvoll überblicken kann, und möglichst "Eine Funktion für eine Aufgabe" erfüllen).
Sauberer Code kann sogar (trotz minimalen Overheads wegen der Funktionsaufrufe) effektiv schneller sein, da man leichter Fehler, Redundanzen etc. sieht und korrigiert.
Erst wenn man wirklich Probleme mit der Performance feststellt, sollte man mittels eines Profilers die Problemstelle ermitteln, und diese optimieren (Ein Profiler deckt zwar nicht jeden Anwendungsfall perfekt ab, aber man selbst wird in mindestens 90% an der falschen Stelle optimieren).
