PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [C++]Klassen - Instanzieren - Speicher


amida maru
2007-11-10, 17:14:17
Hallo. Ich habe eine ganz kurze Frage. Da meine Sprite Klasse sehr viele Get und Set Funktionen hat wollt ich fragen ob sich das auf die Performance auswirkt und ob beim Instanzieren von einer Klasse auch Speicher für die Funktionen Reserviert wird auch wenn man die Funktion nicht aufruft..?

MfG
amidamaru

Trap
2007-11-10, 17:24:23
Methoden gehören in C++ zur Klasse und nicht zu den Instanzen. Instanzen enthalten nie Speicher für Methoden, egal ob man sie aufruft oder nicht.

Monger
2007-11-10, 17:25:43
Das letzte worum du dir Sorgen machen solltest, ist Performance. Sowas nennt man "premature Optimizations".

Aber ich kann dich beruhigen: Getter und Setter drücken nicht auf den Speicherverbrauch.

amida maru
2007-11-10, 18:00:58
ok gut weil die Sprite Klasse hat so viel set und Get funktionen...

rotalever
2007-11-10, 18:23:22
Getter und Setter können sich aber trotzdem auf die Geschwindigkeit auswirken, da ein Funktionsaufruf i.d.R. mehr Zeit benötigt als ein einfacher Variablenzugriff. In den meisten Fällen wirkt sich dies natürlich nicht auf die Gesamtperformance aus, da diese Funktionen meistens verhältnismäßig wenig aufgerufen werden. Also sollte man sich da zunächst keine Gedanken machen. Solche Optimierungen würde ich erst machen, wenn das Programm in einem Zustand ist, in dem es sich lohnt Geschwindigkeitsoptimierungen zu machen. Und da gibt es einige Tricks... Ohne irgendwelche speziellen Algorithmen zu ändern, kann man nämlich später oft eine ganze Menge an Geschwindigkeit rausholen, in dem Berechnung gecached oder optimiert werden (Formeln auf günstige Schreibweise bringen, pow(x,2) = x*x, etc.)

del_4901
2007-11-10, 18:28:33
Getter und Setter können sich aber trotzdem auf die Geschwindigkeit auswirken, da ein Funktionsaufruf i.d.R. mehr Zeit benötigt als ein einfacher Variablenzugriff. In den meisten Fällen wirkt sich dies natürlich nicht auf die Gesamtperformance aus, da diese Funktionen meistens verhältnismäßig wenig aufgerufen werden. Also sollte man sich da zunächst keine Gedanken machen. Solche Optimierungen würde ich erst machen, wenn das Programm in einem Zustand ist, in dem es sich lohnt Geschwindigkeitsoptimierungen zu machen. Und da gibt es einige Tricks... Ohne irgendwelche speziellen Algorithmen zu ändern, kann man nämlich später oft eine ganze Menge an Geschwindigkeit rausholen, in dem Berechnung gecached oder optimiert werden (Formeln auf günstige Schreibweise bringen, pow(x,2) = x*x, etc.)
Optimiert das Design tot!
Da macht Amida wenigstens eine Sache richtig, und ihr erzählt im sowas.
Ich hab Jahre gebraucht um mir Setter und Getter anzugewöhnen, und ich bin immernoch zu faul dafür ... blos gut, das es refactoring Tools gibt.

Ectoplasma
2007-11-10, 20:10:08
Es kommt darauf an, ob die getter und setter mit virtual deklariert wurden. Und dann belegen sie jeweils einen Slot in der V-Table. Das sind 4 Byte bei 32-Bit-Systemen pro virtueller Methode. Mag nicht viel sein, aber ...

Neomi
2007-11-10, 20:52:39
ok gut weil die Sprite Klasse hat so viel set und Get funktionen...

So ist das auch richtig. Beim Debuggen kann das richtig viel bringen (z.B. Assertions in Settern), im Release-Build kostet es nichtmal Performance (wenn richtig umgesetzt).

Laß dich nicht auf "Optimierungen" ein, die das Design der Software betreffen, außer natürlich algorithmische Optimierungen. Taktzyklenjagd ist Aufgabe des Compilers und der kann solche Dinge sehr gut erledigen, wenn man ihn ein wenig unterstützt. Da wären z.B. konstante Referenzen, wenn Strukturen als Parameter übergeben werden oder Methoden, die als konstant markiert werden, wenn sie das Objekt nicht verändern (z.B. Getter). Und dank Inlining sind Setter und Getter sowieso nichts, was man vermeiden sollte.

Es kommt darauf an, ob die getter und setter mit virtual deklariert wurden. Und dann belegen sie jeweils einen Slot in der V-Table. Das sind 4 Byte bei 32-Bit-Systemen pro virtueller Methode. Mag nicht viel sein, aber ...

Virtuelle Setter und Getter sind sowieso eine sehr seltene Sache. Und virtuelle Methoden generell belegen zwar Speicher in der VTable, aber die wird nicht pro Instanz angelegt, sondern nur referenziert. Relevant ist für die Größe einer Instanz nur, ob eine Klasse überhaupt virtuelle Methoden und damit eine VTable hat, aber nicht die Zahl der virtuellen Methoden selbst.

Monger
2007-11-11, 00:42:41
...Solche Optimierungen würde ich erst machen, wenn das Programm in einem Zustand ist, in dem es sich lohnt Geschwindigkeitsoptimierungen zu machen.

... also nie. Heute schreibt man keine Software mehr, die danach nie wieder angerührt wird. Und wer die Wiederverwendbarkeit von Code kastriert indem er Getter und Setter reduziert nur um ein paar Byte rauszupressen, sollte schnellstmöglich auf irgendeiner einsamen Insel ausgesetzt werden.

rotalever
2007-11-11, 14:40:37
... also nie. Heute schreibt man keine Software mehr, die danach nie wieder angerührt wird. Und wer die Wiederverwendbarkeit von Code kastriert indem er Getter und Setter reduziert nur um ein paar Byte rauszupressen, sollte schnellstmöglich auf irgendeiner einsamen Insel ausgesetzt werden.
Sag ich ja gar nicht :( Optimierungen soll man eher an anderer Stelle machen, wollte ich sagen

tokugawa
2007-11-11, 18:42:04
Sag ich ja gar nicht :( Optimierungen soll man eher an anderer Stelle machen, wollte ich sagen

Optimierungen sollte man nicht an fixen Stellen machen von denen man vermutet dass sie helfen.

Niemals optimieren bevor man per profiling rausgefunden hat, wo eigentlich der Bottleneck liegt!

Sonst kann Optimierung schon mal enttäuschend wenig bis Null bringen.

Aus der obigen Regel ist auch logisch ableitbar, dass man nicht vorzeitig optimieren sollte, da in frühen Stadien der Entwicklung das Programm noch nicht so fertig ist, dass dort die Performance-Verhältnisse auch dem finalen Programm entsprechen (sprich, das Profiling wär damit verfälscht).

Und, was sehr viele erfahrene Entwickler richtig sagen (auch hier), natürlich: eine Optimierung die Code unlesbarer oder unwartbarer macht (sprich, das Design beeinträchtigt), sollte man auch nicht machen, oder zumindest nicht ohne sehr guten Grund (und eine Performancesteigerung von 100 fps auf 105 fps ist kein guter Grund!). Damit schießt man sich auf lange Sicht selbst in den Fuß.


Diese Dinge kann man alle gar nicht oft genug betonen, denn grad im Internet gibt's leider sehr viele autodidakte "Coder/Progger/Hax0r", die oft meinen per häßlichstem Code alle möglichen Optimierungen machen zu müssen, und dabei nicht mal analysieren ob diese überhaupt etwas bringen.

RMC
2007-11-11, 19:01:00
Wiederverwendbarkeit und Übersichtlichkeit geht natürlich vor.

Kein vernünftiger Programmierer käme auf die Idee an einem lauffähigen Programm wegen ein bisschen Performance viel rumzudoktoren, wenn es eines dieser zwei Bereiche massiv gefährdet. Eher macht man noch das Gegenteil, man optimiert im Sinne der Usability.

Wenn man aber das Problem sehr genau eingrenzen kann und man die beiden Aspekte beachtet, ist es natürlich schon "erlaubt".

Am besten ist eine gute vorhergehende Planung bei performancekritischen Programmteilen, so dass man dieses Problem im Vorfeld vermeidet. Man kann ja auch das Programmdesign so auslegen, dass die eventuell zu optimierenden Teile sehr leicht zugänglich sind und im Fall der Fälle wenig Änderungen bedürfen.

malte.c
2007-11-15, 17:36:36
Es kommt darauf an, ob die getter und setter mit virtual deklariert wurden. Und dann belegen sie jeweils einen Slot in der V-Table. Das sind 4 Byte bei 32-Bit-Systemen pro virtueller Methode. Mag nicht viel sein, aber ...

Die müssen aber nicht zwingend pro Instanz abgelegt werden, da die V-Table bei Instanzen der gleichen Klasse auch gleich ist. Ein Pointer auf die Klassen-V-Table sollte also ausreichen, egal wie viele virtuelle Funktionen enthalten sind.