Fehlerhafte Speicherfreigabe bei Anzeige von JPG-Files?
Moderator: Moderatoren
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Fehlerhafte Speicherfreigabe bei Anzeige von JPG-Files?
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?
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
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
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
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Olaf,
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
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.Lewi hat geschrieben:ich habe eben getestet. Auch bei mir wird der Speicher nach Programmminimierung freigeben.
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!).Lewi hat geschrieben:Ich halte das schlichtweg für einen Bug, falls es keine "programmtechnische" Lösung gibt.
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Tom,
Man könnte es ja mal mit dem smartGC von den Russen versuchen...
Viele Grüße,
Martin
da hast Du sicherlich auch Recht!Tom hat geschrieben:Nach meinem Kenntnisstand sollte man auf die Speicherauslastungs-/-belegungsdaten, die Windows (auch XP) liefert, nicht allzu viel geben.
Man könnte es ja mal mit dem smartGC von den Russen versuchen...
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
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...
Unverständlich ist warum aber Anfangs fast der 100 fache Speicher belegt wird...
Gruß
Hubert
Hubert
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Tom,
Du sollst Dich auskurieren!!!
Gute Besserung,
Martin
Du sollst Dich auskurieren!!!
Gute Besserung,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Hallo, Martin.
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.smartGC testen
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
Ich nehme doch mal an, dass Deine Tests mit der 1.82 liefen, oder?
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9361
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16514
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.