Performanceunterschiede?
-
gibts einen performance unterschied zwischen den folgenden display funktionen?
class a{ private: int b; public: void display(){//nr1 cout<<b; } }; class b{ private: a A; public: void display(){//nr2 A.display(); } };
-
Die Frage stellt sich nicht, weil die beiden Codestücke nicht das selbe machen oder austauschbar sind.
(Und zum Glück besteht bei deinem Code keinerlei Gefahr, Namen zu verwechseln)
-
die frage die sich mir stellt ist, ob es performancemäßig vertretbar ist, Klassen in kleinen Stücken zu Kapseln, unter der gefahr, dass man etwas schreiben muss, wie es hier im beispiel steht.
-
Nenn doch bitte schon einen Grund warum es performancemäßig nicht vertretbar sein sollte wenn du Zweifel hast. Btw ist "a A" extrem hässlich!
-
ist doch nur ein beispiel-.-
-
Aber ein schlechtes. Es ist wie Optimizer gesagt hat: Die beiden Codestücke machen nicht das selbe!
-
Sowas ist generell Bloedsinn. Wenn es sinn macht eine Klasse zu kapseln, dann sollte man es auch machen. Man waere ja bloed, wenn man fuer eine handvoll Taktzyklen ein mieses Design in kauf nimmt...
Solche mini optimierungen machen ja eh nichts aus - man soll dort optimieren wo es sinn macht.
-
Hallo,
dir ist aber schon klar, dass die Ausgabe auf cout um mindestens eine Größenordung langsamer ist, als der Aufruf einer Funktion?
-
ich brauchte *irgendetwas* in der funktion, weil sonst wieder ein kommentar kommt wie "wozu eine funktion die nichts macht", naja aber wie mans macht, macht mans falsch
-
Ich finde es macht durchaus Sinn eine Funktionalität wie sie in "a" steht in eine
Klasse zu kapseln, wozu aber diese Funktionalität doppelt kapseln?
Egal ob du direkt mit a arbeitest oder "a" über "b" bearbeitest, es ändert sich
ja nichts, außer der Dauer der Ausführung. Leicht änderbar ist "a" auch ohne "b",
sprich von Konsolenausgabe, auf Netzwerkausgabe o.ä. umzusteigen.Daher finde ich das Konzept unschlüssig.
-
Hallo,
also ich würde das Problem erstmal logisch zerlegen. Wenn sich dann rausstellt, dass eine *konkrete* Objektkomposition ein Performance-Problem darstellt (gemessen nicht geraten), kannst du die Komposition immer noch auflösen. Genrell hat die Komposition natürlich eine Indirektion mehr. Hier also ein zusätzlicher Funktionsaufruf. Das ist aber im Allgemeinen a) überhaupt kein Problem und b) kann inline hier zur Not helfen.
Wie auch immer: Solche Sachen diskutiert man lieber an konkreten Problemen.
-
Könnt mich ja auch täuschen, aber bei einer so realisierten Komposition sehe ich eigentlich keine Indirektion. Werden hier nicht die Datenelemente der Klasse a neben die Datenelemente der Klasse b gestellt? Es nimmt ja auch sizeof(b) dadurch zu.
Aber wie auch immer, selbst wenn es so ist, es ist einfach nur noch egal.
-
Optimizer schrieb:
Könnt mich ja auch täuschen, aber bei einer so realisierten Komposition sehe ich eigentlich keine Indirektion. Werden hier nicht die Datenelemente der Klasse a neben die Datenelemente der Klasse b gestellt? Es nimmt ja auch sizeof(b) dadurch zu.
Hae? Was meinst du
?
-
Ich habe Hume's Satz so verstanden, dass in diesem Fall in b ein Zeiger auf ein a - Objekt existiert, das a - Objekt also nur indirekt verwaltet wird.
Jetzt würde ich das aber gern genau wissen, weil so weit ich weiss, werden die Datenelemente von a einfach nur ein Teil von b und es gibt keine Indirektion mehr.
Kann mich aber auch täuschen. Ich will's eigentlich nur wissen, weil mich das jetzt grad interressiert.
-
Hallo,
lies meinen Beitrag noch mal genau und du solltest verstehen. Ich habe geschrieben, worin in diesem Fall die zusätzliche Indirektion besteht. Mit Pointern hat das nichts zu tun.
-
Ups.
Aber lieg ich jetzt damit richtig, dass die Datenelemente einfach zur Klasse dazugehören, als wären sie direkt darin definiert (technisch)?
Das wollte ich ja eigentlich wissen.