Performance: Get-Metode vs. Direkt Member Zugriff??
-
hallo
ihr ich hab ein Array und möchte da zugreifen nun gibt es eine entscheidungsproblem:
1. Get/Set elengater und Information-Hiding vorteil aber evtl langsam (oder?)
2. direkt zugriff auf puplic Member schneller (oder?)grüße
-
Wenn der getter inline ist (und das sollte er vermutlich sein, da er nur das Array zruückgibt), ist kein Performance-Unterschied vorhanden. Und selbst wenn der getter das nicht ist, wird dieser Funktionsaufruf deinem Programm nicht das Genick brechen (außer dein Programm besteht nur aus einer Schleife, die diese Funktion aufruft^^).
-
Get/Set kannst du idR als Inline-Funktion schreiben, dann optimiert der Compiler die Funktionsaufrufe direkt heraus (und die Geschwindigkeit beider Ansätze wird (fast) gleich sein). Ich würde auf jeden Fall lieber Get/Set-Methoden verwenden - da habe ich die Kontrolle, wer was mit meiner Klasse macht (über public Member kann der Anwender viel kaputtmachen, ohne daß du dort eingreifen kannst).
-
naja ich hab ein berechne algorithum , welcher auf perfomance aus ist , und der greift auf elemen von array zu ! es sind rel. viele zugriffe bei eienr berechnung .. deswegen frag ich:)
-
Wenn Du Dir darüber Gedanken machst kannst Du auch eine Referenz halten
(wenn es viele sequentielle Zugriffe sind sieht das sogar schöner aus)MyArray const& daten = objekt.GetDaten(); /* ... */ daten[i] /* ... */ daten[i+1] /* ... */ daten[i-1] /* ... */im Vergleich zu
/* ... */ objekt.GetDaten()[i] /* ... */ objekt.GetDaten()[i+1] /* ... */ objekt.GetDaten()[i-1] /* ... */In einer Schleife, in der nur pro Durchlauf einmal auf das Array zugegriffen wird, ist das natürlich weniger optisch hilfreich als vielmehr zur Reduzierung Deiner (unbegründeten, wenn inline) Performance-Sorge.
-
Ich weiß nicht, was alle immer mit Performance haben. Schreibt doch einfach den Code. Ganz normal, ohne dass man sich schon über Optimierungen den Kopf zerbricht. Dann lässt man den Code mal durchlaufen und macht Laufzeittests. Ist er schon jetzt schnell genug, hab ich mir 'ne Menge unnötige Optimierungen gespart, die vermutlich eh negative Auswirkungen gehabt hätten und kann mich anderen Dingen widmen.
Ist der Code jedoch zu langsam, schaue ich genau, was den Code langsam macht. Vllt. sind es die Funktionsaufrufe, vllt. ist es die Datenstruktur, vllt. nur eine bestimmte Operation auf die Datenstruktur, vllt. ist aber auch der Algo scheiße.
Wenn ich dann weiß, was genau bremst, kann ich anfangen Optimierungen durchzuführen, die wirklich einen Effekt haben.Wir wissen ja, was Hoare zu dem Thema sagt: "Der frühe Vogel fängt den Wurm" ... äh, na ja. Eigentlich: "Zu frühe Optimierung ist die Wurzel allen Übels."
-
@GPC; Der Code ist schon voll Funktionfähig... jetzt wo das Programm fertig ist .. mach ich mir noch bischen gedanken über optimierungen... Grüße
-
Um es ganz klar auszudrücken: Member-Variablen mache ich immer private. Wenn ich lesenden Zugriff benötige, gibt es eine getter-Methode, die in der Regel inline ist und bei schreibenden Zugriff eine setter-Methode.
Eine Getter darf aber auch keine Referenzen oder Zeiger (ausser const) auf interne Strukturen liefern. Ein Zeiger auf ein Array zu liefern (auch ein const-Zeiger) verbietet sich, da dieses eine bestimmte Implementierung voraussetzen würde.
Inline Getter sind genauso schnell, wie direkte Zugriffe. Selbst wenn ich im Getter noch z. B. eine Index-Variable mitgebe, optimiert der Compiler das raus.
Benötige ich das gesamte Array zur Verarbeitung, ist zu überlegen, ob die Verarbeitungsmethode nicht in die Klasse selbst gehört.
Es gibt nur sehr selten in C++ den Bedarf, aus Performancegründen etwas unsauber zu implementieren. Genau dafür schätze ich C++.
Tntnet
-
Warum schreibt ihr eigentlich immer was von inline? Jeder vernünftige Compiler sollte so schlau sein, und Member-Funktionen die nur ein return x oder x = y haben, autom. inline machen. Darueber mache ich mir absolut keine Gedanke. Muesste ich dieses tun, wuerde ich meinen Compiler wegschmeissen!!!
-
Artchi schrieb:
Warum schreibt ihr eigentlich immer was von inline?
Ich nahm an, dass die Methode im Header gleich definiert wurde, ergo implizit inline. :xmas1:
-
Artchi schrieb:
Warum schreibt ihr eigentlich immer was von inline? Jeder vernünftige Compiler sollte so schlau sein, und Member-Funktionen die nur ein return x oder x = y haben, autom. inline machen. Darueber mache ich mir absolut keine Gedanke. Muesste ich dieses tun, wuerde ich meinen Compiler wegschmeissen!!!
Sollte
(und meistens entscheidet der Compiler sowieso selber, was er inlinet)
Aber es gibt Situationen, wo selbst ein einfaches "return irgendwas" nicht mehr inline aufgelöst werden kann (z.B. bei virtuellen Funktionen oder wenn du die Definiton in eine eigene Übersetzungseinheit auslagerst), deshalb sollte man solche Getter/Setter schon inline-tauglich anlegen.
-
BorisDieKlinge schrieb:
@GPC; Der Code ist schon voll Funktionfähig... jetzt wo das Programm fertig ist .. mach ich mir noch bischen gedanken über optimierungen... Grüße
Falscher Ansatz. Keine "Gedanken" über Optimierung machen, sondern:
- Profiler laufen lassen
- Bottlenecks identifizieren.
- diese dann gezielt optmieren
- Mit Profiler prüfen ob die Optimierung auch gegriffen hat (vorher/nachher vergleich)Alles andere fällt unter den Begriff "premature optimizing".
-
ich versteh nich profiler , bottlenecks... höäää?
-
-
CStoll schrieb:
Artchi schrieb:
Warum schreibt ihr eigentlich immer was von inline? Jeder vernünftige Compiler sollte so schlau sein, und Member-Funktionen die nur ein return x oder x = y haben, autom. inline machen. Darueber mache ich mir absolut keine Gedanke. Muesste ich dieses tun, wuerde ich meinen Compiler wegschmeissen!!!
Sollte
(und meistens entscheidet der Compiler sowieso selber, was er inlinet)
Aber es gibt Situationen, wo selbst ein einfaches "return irgendwas" nicht mehr inline aufgelöst werden kann (z.B. bei virtuellen Funktionen oder wenn du die Definiton in eine eigene Übersetzungseinheit auslagerst), deshalb sollte man solche Getter/Setter schon inline-tauglich anlegen.Dem möchte ich mich anschliessen. Ich verwende fast nie das Wort "inline", sondern achte darauf, wie ich meine Methoden schreibe, damit der Compiler eine Chance hat, das zu optimieren. "inline-tauglich" ist das richtige Stichwort. Die Implementieriung einfacher Getter oder Setter gehören in den Header. Damit gebe ich dem Compiler die Informationen, die er benötigt. Man sollte das durchaus im Hinterkopf behalten, wenn man Code schreibt.
Aber wirklich nur im Hinterkopf. Nicht das aus so einer Nebensache dann die Hauptsache wird. Beim Programmieren sollte man sich in erster Linie auf das Problem konzentrieren und nicht auf die Optimierung.
Tntnet