optimales memory management?
-
Hallo Leute.
ich habe einen gepufferten ausgabe stream. dieser puffert alles und schreibt erst am ende den inhalt nach cout.
ich frage mich gerade wie man das am besten realisieren kann -> das puffern meine ich.
momentan ist es so:
user kann eine bestimmte puffergroesse bestimmen, wenn nicht gibt es eine standard groesse (so wie bei normalen streams)
wenn diese puffer nun voll ist, wird der inhalt in eine single linked list geschrieben -> diese linked list speichert pro element einen zeiger auf den speicher mit dem puffer inhalt (muss natuerlich vorher kopiert werden) und die groesse des strings.
dann am ende muss ich daraus wieder einen string bauen. also erstmal die single linked list durchlaufen und alle groessen zusammenzaehlen (OK, die groesse kann man natuerlich schon beim eintragen in die liste 'cachen') - denn speicher allokieren und wieder die ganze liste durchlaufen und die verschiedenen strings in den grossen string schreiben (und dabei die alten strings freigeben).
das ganze soll fuer strings mit einer gesamtlaenge bis zu 120KB effektiv laufen. meistens werden die strings aber kleiner sein.
was haltet ihr davon? ist es bei so kleinen strings egal, oder kann man da noch etwas verbessern?
-
Ich versteh nicht, wieso das zum Schluß alles in einen String kopiert werden muß.
-
Bashar schrieb:
Ich versteh nicht, wieso das zum Schluß alles in einen String kopiert werden muß.
muessen tut es nicht, aber wenn der user eine oder mehrere callback funktionen registriert, muessen die den ganzen string bekommen.
zB kann er komprimiert werden, oder auf Fehlerueberprueft, oder sonstwas.
sollte natuerlich keine callback funktion registriert sein, wird der string natuerlich nicht kopiert.
-
Gerade die Vermischung von sehr vielen kleinen und dann wieder sehr grossen Speicheranforderungen bringt das (unsichtbare) Speichermanagement vermutlich ganz schnell ins Schwitzen. Findet dieser Wechsel öfters statt, und von den kleinen Strings bleiben zudem noch einige am Leben, kann es zum Zusammenbruch eines Programmes kommen, new findet nichts mehr (und mit der Programmierung des newhandlers zwecks garbage collection ist es so eine Sache, da schaut mich der MSVC nur dumm an).
Ich würde bei einer solchen Gefahr tatsächlich entweder vorher schon einen grossen Speicherbereich am Stück reservieren (um sicherzugehen, dass er noch vorhanden ist, wenn es soweit ist - aber das entspricht nicht gerade schönstem C++), oder zeitweilig notfalls über Platte gehen, und dann die kleinen Bereiche notfalls komplett abmelden und restaurieren.
-
Bitsy schrieb:
Gerade die Vermischung von sehr vielen kleinen und dann wieder sehr grossen Speicheranforderungen bringt das (unsichtbare) Speichermanagement vermutlich ganz schnell ins Schwitzen.
oh, da habe ich mich wohl falsch ausgedrueckt.
180KB wird der gesamt string maximal lang sein.
die teilstrings sind alle gleich lang - denn der user bestimmt wie gross der buffer ist (und jedesmal wenn der buffer voll ist, wird der inhalt in meine single linked list eingetragen und der buffer geleert.ich habe es also mit kleinen strings zu tun.
-
Bitsy schrieb:
Gerade die Vermischung von sehr vielen kleinen und dann wieder sehr grossen Speicheranforderungen bringt das (unsichtbare) Speichermanagement vermutlich ganz schnell ins Schwitzen.
ich fürchte, das ist hier ohne belang.
wir reden von ein paar hundert k. mag es mal doof kommen und ein paar mb seien futsch. das merkt keiner. wenn pages lange nicht gebraucht werden, hüpfen sie eh in die auslagerungsdatei. also reden wir über die 4gb adressraum. also ich würde sagen, die sind nicht in gefahr.ich würde mich über ein demo-programm freuen, das die operator new vom msvc so richtig ins schwitzen kriegt. sowas, wo der user während des programmlaufs nicht mehr als 1mb gleichzeitig belegt hat aber nix mehr kriegt.
-
Müsste man mal drüber nachdenken. In der richtigen Reihenfolge bestimmte kleine und sehr grosse Patterns an- und abmelden... Mein Bauch sagt mir, dass es wohl möglich sein sollte.
Habe übrigens nicht erwartet, dass die Größenordnung bei Shade doch nicht so gross ist.
-
änder die schnittstelle von der callback funktion, lasse sie ein deque erwarten (intern würdes du dann auch mit deque arbeiten)
-
Dimah schrieb:
änder die schnittstelle von der callback funktion, lasse sie ein deque erwarten (intern würdes du dann auch mit deque arbeiten)
dann muss der user sich eben selber den string bauen - und das uU mehrmals (denn er kann beliebig viele callbacks registrieren)
ich denke, meine variante ist garnicht so schlecht.
denn ein intelligenter user, setzt die buffer groesse einfach auf die richtige groesse - dann kostet das string bauen nur 1mal kopieren.