C++ Memberfunktion - Speicherverbrauch

[IfindU]

Hallo,

ich arbeite gerade an einem Programm wo ich sprichtwörtlich jeden Byte brauche. Das Programm reserviert haufenweise structs, die allerdings ein paar member Funktionen haben.
Meine Frage ist: reserviert C++ für jeden struct seine eigene Funktion, und sollte beim speichersparen anders gelöst werden, also eine externe Funktion, die darauf arbeitet, oder realisiert C++ das schon nur durch eine Funktion?

Danke schonmal.

 

[[GP] mino]

mach mal sizeof(dein_struct).

 

[1668mib]

An sich hängts vom Compiler ab, aber wäre mir fremd, dass es einen Compiler geben würde, der für jede Instanz den Methoden-Code neu im Speicher unterbringt...

Aber ehrlich gesagt überrascht mich, dass eine solche Frage von jemandem kommt, der um jedes Byte bim Optimieren kämpft...

@[GP] mino: sizeof(Post #2) = 0

 

[ghorst]

Memberfunktionen werden wie ganz normale Funktionen genau einmal abgelegt. Die Menge der Memberfunktionen hat keinen Einfluss auf die Größe des entstehenden Objektes.

Es wird lediglich ein zusätzlicher Pointer benötigt, wenn du virtuelle Funktionen benutzt (Eine Pointer unabhängig von der Menge der virtuellen Funktionen). Wenn du auf jedes Byte achten musst, solltest du möglichst viele Objekte ohne virtuelle Funktionen schreiben.

 

[[GP] mino]

@1668mib, dass die memberfunktionen nur einmal im ausführbaren speicher abgelegt werden, sollte der TE selber rausfinden. hat er mehr von.

sollte das denn noch nicht erwünscht sein, siehe inline-funktionen.

 

[IfindU]

Danke euch,
@1668 bin recht neu im objektorientierten und ich versuche so gut ich kann jeden Byte zu sparen, heißt nicht dass ich es besonders gut schaffe.

 

[1668mib]

Und was hat sizeof mit der Menge an Speicher zu tun, die für Code reserviert werden muss oO

@IfindU: Sorry, aber nen Anfänger optimieren zu lassen halte ich halt irgendwie für begrenzt sinnvoll... aber hängt halt auch vom Projekt ab...

 

[asdfman]

ich arbeite gerade an einem Programm wo ich sprichtwörtlich jeden Byte brauche.

Dann wähle eine für deinen Zweck geeignetere Sprache, wie beispielsweise C oder Assemblersprache. C++ ist da halt ein wenig bloatig (wenn auch nicht so sehr wie andere Monster).

 

[IfindU]

Okay, jeder Byte war womöglich etwas überspitzt formuliert, dass der Algorithmus für größere Testinstanzen beim Lösungsversuch nicht meinen RAM komplett flutet wär wohl eher angebracht gewesen. Und da er dafür eben locker Millionen, wenn ich Größenordnungen mehr eines structs reserviert, wollte ich da nicht komplette Funktionen an Speicher jedesmal rumliegen haben.

 

[antred]

Dann wähle eine für deinen Zweck geeignetere Sprache, wie beispielsweise C oder Assemblersprache. C++ ist da halt ein wenig bloatig (wenn auch nicht so sehr wie andere Monster).

C++ ist aber auch nicht das geringste bißchen 'bloatiger' als C, wenn du dich auf eine für den Anwendungszweck sinnvolle Untermenge von C++ beschränkst.

 

[1668mib]

@IfindU: Wieviel RAM hast du überhaupt verbaut?

 

[IfindU]

Es sind 2GB, es gibt wohl noch eines an Sparpotential, allerdings gibt es ein Approximationsalgorithmus, d.h. es gibt kein Beschränkung für den Speicherhunger, ich wollte es nur etwas näher als den Faktor 40 approximieren. Bin jetzt beruhigt, dass die Memberfunktionen nur konstant viel Speicher brauchen, kann ich mich um andere der vielen Baustellen kümmern.

 

[IceMatrix]

Riecht für mich nach einer schlechten Software
Um was für ein Programm handelt es sich? Wozu die vielen structs?

 

[convexus]

wenn du die Struct's dynamisch aus dem Freispeicher allokierst, lohnt es darüber nach zu denken die Speicher dafür selbst zu verwalten. Also etwa einen Pool mit den Struct's in einen größeren Speicherblock anzulegen und selbst verwalten. C++ bietet hier sehr gute Möglichkeiten z.B. durch Definition von struct-spezifischen new- und delete-Operator.

 

[toeffi]

PrematureOptimization
Ich weiß ja nicht wie weit du schon mit deinem Programm bist, aber eh ich mir über Optimierung Gedanken mache, würde ich es erstmal zum laufen bringen und mir nicht um die C++-Internen Techniken sorgen machen, die sind sowieso Hoch-optimiert, alles was also schlecht sein kann ist dein Quellcode und den kannst du dann optimieren wenn du in Speichernot gerätst. Aber das ist nur ne Vermutung weil ich eben nicht weiß an welchem Punkt der Entwicklung du dich gerade befindest.

 

[kuddlmuddl]

Außerdem würd ich auch erstmal die verschiedenen automatischen Optimierungsmöglichkeiten deines Compilers durchprobieren - oder hast du die schon an?
Wenn ich mich richtig erinnere könnte man bei Visual-Studio auch zwischen small/fast wechseln

 

[7H3 N4C3R]

Was interessant sein kann ist die Größe (sizeof) der Structs und wie sie allokiert werden. malloc reserviert in der Regel mindestens um die 100 Bytes, bei new sind es meist mindestens 16. Wenn ein Struct jetzt nur wenige Bytes braucht (Fliegengewicht), kann das ein Problem werden. In solchen Fällen entweder einen Small-Object-Allocator einsetzen (gibt es einige fertige) oder einfach alles oder zumindest stufenweise in dynamische Arrays oder Vektoren packen.