Weiss eigentlich jemand wieviel Speicherplatz eine std::string /bzw. std::vector Instanz verbraucht)?
Also bei std::string z.B.
- im unbenutzten Zustand
- mit 300 bytes beschrieben
- mit emptry wieder geleert.
Wollte mir bei Tage nochmal den MB zwecks Speicheroptimierung anschauen. Mit dem IF werden ja jetzt wohl alle Bytes gebraucht.
Ich hätte die Frage natürlich auch in einem hardcore-Linux-C++-Forum schreiben können, aber ich dachte ich versuche es erstmal hier
Danke
Günther
std::stringvund std::vector RAM verbrauch
-
- Developer
- Beiträge: 587
- Registriert: Freitag 9. September 2005, 20:48
-
- Interessierter
- Beiträge: 73
- Registriert: Samstag 31. Juli 2004, 17:15
-
- Developer
- Beiträge: 809
- Registriert: Montag 4. Juli 2005, 17:45
Danke dies ist sehr hilfreich. Allerdings wird die uClibc++ oder stdc++ zusätzlich benötigt (Im Tuxbox soundso vorhanden).Muttersöhnchen hat geschrieben:http://speedup.superhits.ch/charstring.html
Bei der Portierung des WebServers auf AVM bzw. mein NAS-Storage fällt dies z.B. aber sehr ins Gewicht.
Gruß
yjogol
FAQ zu YWeb unter http://www.yjogol.de
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Ich versuchte das switch-Programm umzuschreiben, und habe avswitch http://www.tuxbox.org/forum/viewtopic.php?t=41986 geschreiben. "Supercooles C++", in wesentichen gleiche Funktionalität, aber (viel) besseres Design.
Die Ausführbare switch ist 10308 bytes, avswitch 38612 bytes
Die Ausführbare switch ist 10308 bytes, avswitch 38612 bytes
-
- Developer
- Beiträge: 587
- Registriert: Freitag 9. September 2005, 20:48
Danke, das bringt mich schonmal ein Schritt weiter. Also von der Performance macht es nicht viel aus und bei großen Inhalten beim Speicher auch nicht. Leider zeigt der Test mit 1000 bytes nicht wirklich den Overhead der durch string erzeugt wird. Interessant wäre deshalb wie groß der Unterschied zum Beispiel bei nur z.B. 3 Nutzbytes ist (Mal gesetzt dem Fall string wird sowieso irgendwo genutzt).
Bei 10 000 solcher Variablen kommt wahrscheinlich ganz schön was zusammen....
Wie könnte man das am besten mal selber ausmessen?
Noch mal ne allgemeine Fragen, weil ich mir da nicht ganz sicher bin: Bei einer neuen Instanz einer Klasse werden die ganzen Klassen-Variablen auf den heap gelegt und der Klassencode selber bleibt physikalisch immer an einer Adresse (und wird nicht 'vermehrt')?
Noch was ganz anderes: Im Neutrino code werden viele Klassen innerhalb der Menüdefinitionen Instanziert. z.B.
Könnte man hier nicht eine Menge Speicher sparen, wenn das dynamisch gemacht werden würde (den pictureviewer benutzen wohl die Wenigsten jeden Tag)
+
Hier würde der pictureviewer nur beim ersten Start instanziert und bei bedarf danach gleich wieder gelöscht.
Allerdings, steigt dann durch die Fragmentierung des Codes nicht die Wahrscheinlichkeit, daß irgendwann kein zusammmenhängender Speicher mehr zur Verfügung steht (ich gehe mal davon aus, dass das notwendig ist) um eine Instanz zu erzeugen?
Code: Alles auswählen
char buffer1 = new char[3] ; // heap delta 3 bytes
char buffer[3]; // heap ? delta 3 bytes
CString Buffer; // heap delta overhead+x1?
CString Buffer1 = "ab"; // heap delta overhead+2+x2?
Wie könnte man das am besten mal selber ausmessen?
Noch mal ne allgemeine Fragen, weil ich mir da nicht ganz sicher bin: Bei einer neuen Instanz einer Klasse werden die ganzen Klassen-Variablen auf den heap gelegt und der Klassencode selber bleibt physikalisch immer an einer Adresse (und wird nicht 'vermehrt')?
Noch was ganz anderes: Im Neutrino code werden viele Klassen innerhalb der Menüdefinitionen Instanziert. z.B.
Code: Alles auswählen
mainMenu.addItem(new CMenuForwarder(LOCALE_MAINMENU_PICTUREVIEWER, true, NULL, new CPictureViewerGui(), NULL, CRCInput::RC_3));
Code: Alles auswählen
mainMenu.addItem(new CMenuForwarder(LOCALE_MAINMENU_PICTUREVIEWER, true, NULL, this, "start_pictureviewer", CRCInput::RC_3));
Code: Alles auswählen
int CNeutrinoApp::exec(CMenuTarget* parent, const std::string & actionKey)
{
// printf("ac: %s\n", actionKey.c_str());
int returnval = menu_return::RETURN_REPAINT;
if(actionKey == "start_pictureviewer")
{
if(pictureViewerGui == NULL)
pictureViewerGui = new CPictureViewerGui();
if(pictureViewerGui != NULL)
{
pictureViewerGui->exec(this," ");
if(g_settings.destroyModulesAfterUse == true)
{
delete pictureViewerGui;
pictureViewerGui = NULL;
}
}
else
{
TRACE("WARNING: cannot alloc pictureViewerGui");
}
}
Allerdings, steigt dann durch die Fragmentierung des Codes nicht die Wahrscheinlichkeit, daß irgendwann kein zusammmenhängender Speicher mehr zur Verfügung steht (ich gehe mal davon aus, dass das notwendig ist) um eine Instanz zu erzeugen?