Fehlerhafte Speicherfreigabe bei Anzeige von JPG-Files?

[Lewi]

Ich habe das Phänomen beobachtet, dass bei Anzeige von großen JPG-Dateien xbase++ zunehmend Speicher anfordert, der dann nicht wieder freigegeben wird.

Dieses Verhalten kann mit dem Beispielprogramm von ALASKA ..\ALASKA\XPPW32\SOURCE\samples\apps\ImgView\IMGVIEW.EXE leicht nachvollzogen werden.

Auf meinem Entwicklungsrechner mit 1.25 GB Hauptspeicher nimmt die Anwendung zunächst ca. 7.75 MB Hauptspeicher ein. Nach dem Anzeigen von großen JPG-Dateien (ca. 1 MB) schnellt der Speicherbedarf für Anwendung auf fast 70 MB hoch, die dann nicht mehr freigegeben werden.

Ich habe ein wenig mit der Anzeige von JPG-Dateien experimentiert und festgestellt, dass selbst bei einem „destroy“ von Anzeige-Objekten bzw. ein „release“ von Variablen, der Hauptspeicher nicht wieder freigegeben wird.

Auf meinem Rechner mag dieses Verhalten sicherlich „unkritisch“ sein, auf anderen Rechnern mit <= 512 MB Hauptspeicher (mit Pentium 3) hat dies jedoch zur Folge, dass die Anwendung durch den Hauptspeicherbedarf merklich langsamer wird. In dem beschriebenen Fall werden ca. 60 MB Hauptspeicher für „Nichts“ reserviert!

Ich habe die Vermutung, dass die Ursache im Garbage Collector liegt. Oder hat jemand eine Lösung für dieses Problem?

Nachtrag:
Dieses Verhalten bezieht sich auf die Version 1.82. Ist dieses Verhalten auch unter 1.9 zu beobachten?

[Martin Altmann]

Hallo Olaf,
was passiert denn, wenn Du nach dem Anzeigen (es wird also nichts mehr angezeigt und die 70 MB sind belegt) Dein Programm als Symbol verkleinerst?
Ich wette, dann wird der Hauptspeicher freigegeben und Dein Proggi belegt nur noch knapp 8 MB, richtig?
Ist SWB und taucht bei vielen (allen?) Programmen so auf!
Zu Deiner Frage mit dem Garbage Collector: um das zu verifizieren, kannst Du es ja mal mit 1.9 versuchen?

Viele Grüße,
Martin

[Lewi]

Hallo Martin,
ich fürchte, die Wette würdest Du verlieren. Ich habe es gerade mal ausgetest. Sowohl mit dem Beispielprogramm wie auch auch mit einer eigenen Anwendung. Im Übrigen würde mich das von Dir beschriebene Verhalten auch irritieren, da ich dafür keine plausible Erklärung hätte.

Gruß, Olaf

[Martin Altmann]

Hallo Olaf,
die plausible Erklärung kann ich Dir gerne liefern
Erst durch das verkleinern zum Symbol wird der Garbage Collector in jedem Fall aktiv, da Windows dann erkennt, dass es jetzt die Ressourcen, die von dem Prozeß belegt wurden, aufräumen kann.
Beispiel: mein Opera-Browser, in dem ich das hier gerade tippe.
Er belegt 110MB Speicher.
Als Symbol verkleinert: 11 MB, steigt langsam wieder an auf 22 MB.
Wieder vergrößert um weiter zu schreiben: Jetzt bei knapp 50 MB.
OS: XP.

Viele Grüße,
Martin

[Lewi]

Nun, in der Alaska-Beispielanwendung ist im Voll-Bildmodus ebenfalls der Garbage Collector aktiv. Das läßt sich über dem Systemmonitor nachvollziehen.

[Martin Altmann]

Hallo Olaf,
ich habe das jetzt mal hier nachgestellt.
Ich habe nur eine 555KB große JPG-Datei gehabt.
Das vorkompilierte imgview von Alaska gestartet -> 7,5 MB
Die JPG geladen -> 51 MB
IMGVIEW.EXE minimiert -> 1,5 MB
IMGVIEW.EXE wieder zurückgeholt (Datei wird auch wieder angezeigt) -> 13,9 MB

Ich kann Deine Probleme also so nicht nachvollziehen, sorry!

Viele Grüße,
Martin

[Lewi]

Guten Morgen Martin,
ich habe eben getestet. Auch bei mir wird der Speicher nach Programmminimierung freigeben.
Aber DAS kann ja nicht der Weisheit letzter Schluß sein! Nach dem Motto, "Anwender, minimiere regelmäßig Deine Anwendung, damit Du wieder mehr speicher zur Verfügung hast"
Ich halte das schlichtweg für einen Bug, falls es keine "programmtechnische" Lösung gibt.

Gruß, Olaf

[Tom]

Hallo, Martin, hallo, Olaf.

Nach meinem Kenntnisstand sollte man auf die Speicherauslastungs-/-belegungsdaten, die Windows (auch XP) liefert, nicht allzu viel geben. Wenn ich mich recht erinnere, hat Steffen Pirsig auf der letzten DevCon in den Niederlanden einen langen Vortrag zu diesem Thema gehalten.

[Martin Altmann]

Hallo Olaf,

ich habe eben getestet. Auch bei mir wird der Speicher nach Programmminimierung freigeben.

ach so? Ich dachte, das hattest Du vorher schon ohne Erfolg getestet - zumindest hatte ich Deinen Post vom 28. März 2006, 10:19 so verstanden.

Ich halte das schlichtweg für einen Bug, falls es keine "programmtechnische" Lösung gibt.

wie ich oben bereits schrieb - das ist SWB! Passiert mit allen Programmen so (ausser vielleicht bei Microsoft-eigenen, aber die können ja bekanntlich bei solchen Problemen kein Maßstab sein!).
Workaround: Wenn eine andere Grafik geladen werden soll, das Programm aus Deinem Source heraus minimieren und danach wieder restoren. Wenn das schnell genug geht, sollte es ja kein Problem sein

Viele Grüße,
Martin

[Lewi]

Hi Martin,
das mit dem Minimieren und Restoren nach der Anzeige einer Grafik ist ein guter Tipp.
Danke!

Gruß, Olaf

[Martin Altmann]

Hallo Tom,

Nach meinem Kenntnisstand sollte man auf die Speicherauslastungs-/-belegungsdaten, die Windows (auch XP) liefert, nicht allzu viel geben.

da hast Du sicherlich auch Recht!
Man könnte es ja mal mit dem smartGC von den Russen versuchen...

Viele Grüße,
Martin

[brandelh]

ich habe mal hier eine 5 MB BMP Datei nach JPEG umgewandelt (auf die schnelle mit Paint). Die braucht nur noch 0,5 MB. Bei der Bildschrimanzeige denke ich muß intern aber wieder entpackt und in eine Art von BMP gerechnet werden. Also wären 5 bis 10 MB plausibel, solange die Anzeige nötig ist. Das würde auch erklären warum eine minimierte Anwendung weniger Speicher belegt (Systemresourcen...).

Unverständlich ist warum aber Anfangs fast der 100 fache Speicher belegt wird...

[Tom]

Hallo, Martin.

Wenn smartGC so schnell ist wie die WebSite von denen, dann sehe ich schwarz. Aber ich lade und teste das Dingen jetzt mal.

[Martin Altmann]

Tom,
Du sollst Dich auskurieren!!!

Gute Besserung,
Martin

[Tom]

Huhu, Martin.

Bin wieder fit wie ein ... Dingens. Das, was man anzieht, wenn man dieses andere machen will ... an die Füße. Zeugs. Ach, Turnschuh.

Trotzdem danke für die Besserungswünsche!

[Martin Altmann]

Freut mich, dass es Dir wieder besser geht!
Dann trödel mal nicht so rum hier! Gibt genug zu tun!

• Mod für Sommer/Winterzeit suchen+einspielen
• Mod für Dateiablage suchen+einspielen
• Mod für Umfragen (mehrere Antworten möglich) suchen+einspielen
• smartGC testen
• ...

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

smartGC testen

Ich habe die Trial-Version mal geladen und quick-and-dirty eingebunden. Dann habe ich einige sehr speicherintensive Module mit und ohne SmartGC gegeneinanderlaufen lassen. Es scheint einen Geschwindigkeitsgewinn (etwa bei 10%) zu geben, aber keinen signifikanten (etwa in der Größenordnung "10 times faster", wie sie auf ihrer Site behaupten). Allerdings sind zwei Dinge zu bemerken: Prozesse scheinen - das ist eine Gefühlssache - deutlich schneller zu starten (Aufbau von Dialogen). Und zweitens bleibt die CPU-Auslastung fortwährend in einem deutlich kleineren Bereich. Ich spiele noch ein bißchen mit dem Tool herum. Zehn Prozent Geschwindigkeitsgewinn wären mir durchaus 250 $ wert. Die Frage ist, ob sich dadurch auch das Laufzeitverhalten einer länger aktiven Applikation verbessert (wir haben das in einem anderen Thread diskutiert) - und ob das Ganze nicht hinfällig wird, wenn Alaska mit der 1.9 einen eigenen überarbeiteten GC ausliefert. Irgendwann in 30 Tagen.

[Martin Altmann]

Hallo Tom,
vielen Dank für die Info!
Naja, ob nun 10 Mal schneller oder 1/10 Mal - ist doch fast das gleiche
Allerdings wäre ein Test mit der aktuellen 1.9 auch mal interessant - wenn Du Dich also langweilen solltest...

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Ich weiß von keiner Version 1.9.

[Martin Altmann]

Bööh, Du nimmst das heute aber genau!
Ich nehme doch mal an, dass Deine Tests mit der 1.82 liefen, oder?

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Die Einsneuner wird ja sekündlich erwartet.

Wie ich andernorts schrub - ich habe keine Zeit, meine App mit dieser Beta auf Herz und Nieren zu testen, also fasse ich die erst an, wenn sie offiziell raus ist. Ja, die Test laufen mit der 1.82. Leider kommt der SmartGC-Trial völlig ohne Doku, so daß man nur anhand des Minibeispiels sehen kann, welche Methoden möglicherweise zur Verfügung stehen. Wie gesagt, ein spürbarer Geschwindigkeitsgewinn ist da, und auch die vom Task-Manager angezeigte Speicherlast steigt deutlich geringer an als ohne SmartGC, wenn man ein halbes Stündchen alle möglichen Module aufgerufen hat. Da in der Third-Party-NG von Alaska alle Nachrichten zum Thema SmartGC blind sind (keine Texte), kann ich auch nicht nachlesen, ob jemand Erfahrungen damit gesammelt hat - und welche. Prinzipiell interessiert mich das sehr, aber ich mag auch kein Tool kaufen, das exakt 30 Tage später obsolet wird.

[Martin Altmann]

Hallo Tom,
ist OK! Ich dachte, Du hättest das vielleicht mit dem IMGVIEW getestet.
Was für einen Newsreader nutzt Du denn?? Weiße Schrift auf weißem Hintergrund ist natürlich doof.

Viele Grüße,
Martin

[Lewi]

Ich habe mir die Trail-Version von SmatCG heruntergeladen (mein Gott, dieser Server!) und werde Sie mal in einer größen Applikation einbinden.

Ich werde berichten ....