Was ist fragmentierter Speicher aussehen?

Question

Ich habe eine mobile Anwendung, die von langsam im Laufe der Zeit leidet. Meine Vermutung, (teilweise gespeist von diesem Artikel ,) ist, dass dies zu einer Fragmentierung des Speichers aufgrund ist die App zu verlangsamen, aber ich bin mir nicht sicher. Hier ist eine ziemlich grafische Darstellung der Speichernutzung der App im Laufe der Zeit:

Fraggle Rock http://kupio.com/image-dump/fragmented.png

Die 4 Peaks auf der graphischen Darstellung sind vier Ausführungen der exakt gleichen Aufgabe auf der App. Ich beginne die Aufgabe, eine Reihe von Speicher reserviert, sitzt es für ein bisschen (Die flache Linie oben) und dann stoppe ich die Aufgabe. An diesem Punkt ruft System.gc (); und der Speicher wird gereinigt.

Wie man sehen kann, jeder der vier Läufe der exakt gleichen Aufgabe länger auszuführen. Die Low-Punkte in der Grafik alle zurück auf das gleiche Niveau, so gibt es scheinbar keine Speicherlecks zwischen Task ausgeführt werden.

Was ich möchte wissen, ist, ist die Fragmentierung des Speichers eine mögliche Erklärung oder sollte ich woanders zuerst schauen, wenn man bedenkt, dass ich bereits eine Menge der Suche getan haben? Die Low-Punkte auf dem Graphen sind relativ gering, so meine Vermutung ist, dass der Speicher in diesem Zustand nicht sehr fragmentiert sein würde, da es nicht viele kleine Speicherlöcher sein können Probleme verursacht werden.

Ich weiß nicht, wie die J2ME Speicherzuordner funktionieren, obwohl, so dass ich weiß es wirklich nicht. Kann mir jemand raten? Hat sonst noch jemand Probleme mit diesem hatte und erkennt das Speicherprofil der App?

Answer 1

Wenn Sie ein wenig Zeit haben, können Sie Ihre Theorie testen, indem Sie erneut mit dem Speicher durch Speicher-Pool-Techniken: jeder Lauf der Aufgabe verwendet die ‚gleichen‘ Brocken Speicher, indem sie aus dem Pool und sie bei Release-Zeit zurück.

Wenn Sie immer noch die erniedrigende Aufführung nach dieser Untersuchung zu tun, ist es nicht Speicherfragmentierung verursacht das Problem. Lassen Sie uns alle Ihre Ergebnisse wissen und wir können weiter helfen beheben.

Answer 2

Speicherfragmentierung für sie erklären würde ... was nicht klar ist, ob die Apps Nutzung von Speicher-Paging verursacht? dies würde auch langsam Dinge .... und die gleichen Probleme verursachen könnten.

Answer 3

Es ist das Problem wirklich ist Speicherfragmentierung, gibt es nicht viel Sie dagegen tun können.

Aber bevor Sie in Verzweiflung aufgeben, versuchen Sie Ihre App mit einer Ausführung Profiler laufen, um zu sehen, ob es viel Zeit in einem unerwarteten Ort der Ausführung verbringt. Es ist möglich, dass die Verlangsamung tatsächlich aufgrund eines Problems in der Algorithmen ist und nichts mit Speicherfragmentierung zu tun. Da die Menschen bereits gesagt haben, J2ME Müllsammler sollten nicht von Fragmentierungsproblemen leiden.

Answer 4

Betrachten Sie bei der Garbage Collection Statistiken suchen. Sie sollten viel mehr auf dem letzten Lauf als die erste haben, wenn Ihre Theorie zu halten ist. Ein anderer Gedanke könnte sein, dass etwas anderes isst Ihr Gedächtnis so Ihre Anwendung weniger hat.

Mit anderen Worten, Profiler Zeit:)

Answer 5

Was OS sind Sie diese auf? Ich habe einige Erfahrung mit Windows-CE5 (oder Windows Mobile) Geräten. CE5 Betriebssystemebene Speicherarchitektur ist ganz gebrochen und wird scheitern bald für speicherintensive Anwendungen. Das Diagramm hat keine Waage, aber jeder Prozess bekommt nur 32 MB Adressraum auf CE5. Die VM und gemeinsam genutzte Bibliotheken ihren fairen Anteil an, dass nehmen, wie gut Sie mit ganz wenig übrig bleibt. Der einzige Weg, um dieses ist, um den Speicher, den Sie statt zugewiesen wiederverwenden es zurück zum Kollektor geben und Neuzuweisung später. Das ist natürlich viel mehr Low-Level-Programmierung, als Sie in der Regel in Java tun möchten, aber auf dieser Plattform können Sie von Glück.