Hallo Leute...
Der DebugHeap ist ja normal schon was gutes (ich nehme mal an, von ihm kommen diese 0xcdcd und 0xfeee Muster und nicht von der CRT). Ich lass den daher beim Debuggen immer mitlaufen. Aber... bei unseren Langzeittest (wir führen mehrer Millionen Operationen
auf unserer Datenbank durch), da beobachten wir immer wieder sehr sehr seltsame Dinge. Wir hatten z.B. das Problem, dass in früheren Test die Speicher-Belegung dauernd hoch ging (sah aus wie ein Leak). Und erst als er den physikalischen Speicher fast voll
hatte, wurde wieder was freigegeben. Manchmal jedoch nicht und... ja, ihr kennt das... Speicher voll, Zeug auf die Harddisk, alles wird zum Gähnen langsam... da muss man den Test abbrechen. Wir hatten dies aber meistens nur dann, wenn wir riesen Arrays allozierten
und wieder freigaben... also haben wir das nicht mehr gemacht, sondern den Speicher recyclet (das war Speicher, den wir nur für Verifikationen der Datenbank nutzten, wären also in der Release nicht drin gewesen, daher hatten wir das nicht optimiert). ... das
Verhalten des neuesten Programms ist aber viel verherender. Unser Programm alloziert häufig kleine Blöcke und gibt die wieder frei (Jobs werden erstellt, zusammengebaut, übergeben, ausgeführt, abgebaut... genauso ist das mit Objekten im Cache, die werden gebaut,
behalten und irgendwann wieder entladen) ... das ist eigentlich normales Verhalten (logo, man könnte den Speicher zu recyclen versuchen, aber... der ist oft ungleich lang und daher eigentlich mehr das wozu eine Speicherverwaltung gebaut sein müsste) ... also,
auf jeden Fall allozieren wir viel und geben viel frei... und jetzt schnellen die Laufzeiten plötzlich hoch. Nach einigen Millionen Operationen dauert ein malloc/free plötzlich einige zehntausend (10'000) mal länger als normal... oft hängt der Heap in irgendwelchen
internen Locks für recht lange Zeit... hat da einer Erfahrung damit was man am besten tut dagegen? (ausser den DebugHeap abschalten) ... das ist doch echt sau blöd...
Rudolf
