Objekte zur Laufzeit
-
Was Du wahrscheinlich meinst ist, dass viele new's und delete's langsam sind. Aber wenn der Speicher erst mal angelegt wurde, ist er genau so schnell. Deshalb ist es unter Umständen ratsam, auf die vielen new's und delete's zu verzichten, wenn es irgend wie nur geht. Soll heissen, dass man zwar Speicher braucht, aber bevor man ihn wieder freigibt und später wieder anfordert, sollte man ihn besser gleich behalten. Ich habe mal ein Programm geschrieben, was auch wegen vielen new's und delete's sehr langsam war. Anschliessend habe ich mir eine eigene Speicherverwaltung geschrieben, die ich für diese relevanten Objekte verwendet habe. Meine Erfahrung dabei war, dass "Buddy-Systeme" zwar nicht sehr effizient sind, was die optimale Aufteilung des Speichers angeht, aber dafür sehr effizient. Der Unterschied war nachher zu spüren!
-
Gut, ich probiere mal die Lösung mit der eigenen Speicherverwaltung zur Vermeidung von unnötigen Reservierungen und Freigaben.
Original erstellt von RenéG:
in den Prozessorcache gelegtDer Cache hilft bei dem Problem glaub ich nicht viel weiter. Denn der schnelle Zugriff aus dem Cache gilt ja sowohl für den Stack als auch für den Heap.
Original erstellt von Shade of mine:
a)hat dir dein profiler gesagt
b)bessere algorithmen ... variablen eleminiert
c)machen _muss_zu a)
profiler
zu b) über den Punkt bin ich schon hinaus. allerdings hatte ich noch nicht an
die temporären Variablen gedacht
zu c) aus äußerem Zwang heraus oder gibt es tatsächlich rein programmtechnisch Situationen die eine solche Maßnahme verlangen?
-
Original erstellt von Sprotti:
zu a) profiler ein profiler ist ein programm welches die genaue laufzeit jeder funktion deines programmes analysiert.
Auf deutsch gesagt: ein profiler sagt dir, wo dein programm zu langsam istzu b) über den Punkt bin ich schon hinaus. allerdings hatte ich noch nicht an
die temporären Variablen gedachttja, ohne profiler ist das keine lohnende arbeit. bedenkte die 80-20 regel
(80% der laufzeit werden von 20% deines codes erzeugt - wenn du an der falschen stelle optimierst, bringt das also garnix)zu c) aus äußerem Zwang heraus oder gibt es tatsächlich rein programmtechnisch Situationen die eine solche Maßnahme verlangen?
ja, wenn du zu dem schluss gekommen bist, dass new zu langsam ist fuer deine verhaeltnisse (aber das duerfte theoretisch nicht passieren - da wuerde ich eher noch speicher pools angelgen, etc.)
mein Tipp:
schnapp dir einen profiler (google mal danach) und schau dir an wo dein programm langsam ist. dort kannst du dann optimieren. aber so aus dem bauch heraus bringt nicht viel, denn meistens schaetzt man die laufzeit falsch ein.
-
Ich will noch mal daran erinnern, daß z.B. vector oder deque bereits solche Speicherpools darstellen! Macht man ein vector<T>.push_back(T& t), so wird für das neue Objekt kein neuer Speicher im Heap allokiert, es fällt also kein zusätzliches new an. Dies passiert erst, wenn die Grundanzahl an Objekten nicht mehr ausreicht und ein ganz neues Array angelegt werden muß.
Alternativ wäre dafür noch eine deque<T> interessant.
-
thx@all of u
-
Weg damit.
[ Dieser Beitrag wurde am 26.06.2003 um 12:31 Uhr von Lars editiert. ]
-
[ Dieser Beitrag wurde am 26.06.2003 um 12:31 Uhr von Lars editiert. ]
-
Original erstellt von RenéG:
**Für VC++
_alloca
Allocates memory on the stack.
**MSDN:
The allocated space is automatically freed when the calling function exits.
char string[20]; char* pStr = &string;ist also im Prinzip das selbe wie
char* pStr = _alloca(20);[ Dieser Beitrag wurde am 26.06.2003 um 12:29 Uhr von MaSTaH editiert. ]
-
...
[ Dieser Beitrag wurde am 26.06.2003 um 12:31 Uhr von Lars editiert. ]
-
Original erstellt von MaSTaH:
*```cpp
char string[20];
char pStr = &string;ist also im Prinzip das selbe wie ```cpp char* pStr = _alloca(20); ```**Im prinzip, aber was ist mit
void foo(char const* str, int length) { char* t=_alloca(length); strcpy(t,str); do_something(t); }im prinzip ist _alloca ein moeglichkeit VLAs zu erzeugen
