CM7 VM-Heap Size

  • 13 Antworten
  • Letztes Antwortdatum
C

cleric

Neues Mitglied
3
Ich wollte nur mal mitteilen, dass ich dringend dazu rate, den VM-Heap auf 24MB zu stellen (afaik default für das Milestone von MOTO).

CM7 default ist 32MB und sorgt dafür, dass der Wechsel zwischen einzelnen apps deutlich länger dauert oder zum restart führt - jedenfalls für mich.

Auf Benchmarks für Geschwindigkeitsvorteile von 32MB gebe ich nicht viel. Ich möchte das Handy nutzen können und nicht new records in linpack erreichen.

Gruß
 
stell sie doch auf 16 ; ) dann gehts noch schneller.

bei kleinen werten könntest du aber mit der zeit probleme mit großen apps bekommen, ausserdem wird deine akkulaufzeit und ab und an auch die performance ein wenig drunter leiden weil die cpu öfter im hintergrund rasselt.
das du schneller zwischen den apps wechseln kannst liegt vermutlich daran das sie noch im speicher sind.
geringe vm heaps sind gut für multitasking weil einzelne apps nicht den ganzen ram zumüllen können bevor aufgeräumt wird.
lad dir aus dem market doch das vmtool, das is cm kompatibel, d.h. es überschreibt die cyanogenmod heap size settings, dann kannst du sie auch auf 28 setzen, vielleicht is so ein mittelweg ja am besten.
stell sie nur nicht zu klein.

ich hab aber auch selber gute erfahrungen mit 24 gemacht.
ausserdem hab ich mir das ganze mal angesehen und überlegt warum sogar geräte mit doppelt soviel ram wie das MS nur ne vmheap von ~30 haben.

grundsätzlich hängts aber einfach davon ab was für apps du verwendest und wie du das gerät benutzt.

Auf Benchmarks für Geschwindigkeitsvorteile von 32MB gebe ich nicht viel. Ich möchte das Handy nutzen können und nicht new records in linpack erreichen.

also vm heap 24 ist vielleicht nichtmal für jeden optimal, 32 default passt imo. da wird man sich generell schon was dabei gedacht haben.
der wert 32 ist auch nicht da um die beste performance zu geben sondern ist der mittelweg, weil CM ja auf ner menge unterschiedlicher devices läuft.
die interessierten werden sichs sowieso schon für sich selber richten.

evtl. noch was interessantes weil wir schon beim thema sind:
Device implementations with screens classified as medium- or low-density MUST configure Dalvik to allocate at least 16MB of memory to each
application. Device implementations with screens classified as high-density MUST configure Dalvik to allocate at least 24MB of memory to each
application. Note that device implementations MAY allocate more memory than these figures

ok, mein fehler edit nummer 5k^^

24 scheint also der geringste wert zu sein der für unser MS laut google recommendation passen sollte (16 funktioniert aber auch noch) eigentlich kein wunder das sich MOTO am untersten wert orientiert hat wenn man bedenkt das das MS für seine größe und auflösung recht wenig RAM hat.
 
Zuletzt bearbeitet von einem Moderator:
Richtig - 24MB sind min. rec. ;)

Ich hab mir das auch durchgelesen.

Bisher habe ich noch keine Anwendung gefunden welche nicht mit 24MB funktioniert.
Man sollte immer bedenken, dass der Heap reserviert wird und den ganzen Hintergrundprozessen erlaubt eben diesen Speicher zu füllen.

Grundsätzlich kann ich mir kaum vorstellen, dass die Akkulaufzeit hier eine Rolle spielt - das ist vermutlich ähnlich wie mit dem übertakten - merken tue ich davon nichts. Gemessen habe ich allerdings auch nicht.

Du schlägst mir vor den Heap auf 28MB zu erhöhen - ohne dass es jetzt böse gemeint ist - kannst Du mir eine Anwendung nennen welche nicht mit 24MB läuft oder wodurch ich hier einen echten Vorteil habe? Hin und wieder sind Begrenzungen für Anwendungen auch wichtig um rechtzeitig aufzuräumen ;)

Ich poche nur nochmal auf die BackGround Prozesse...

PS: "Erst" seit 2.0 gibt es Geräte mit einer größeren HS als 16 ...
 
Zuletzt bearbeitet:
mein einziges argument dafür wäre der seltenere gc der einsetzt was deinen akku schont.
ansonsten find ich 24 eh auch gut, weil dir das nicht als argument reicht.
anderes hab ich nicht da ich auch noch keine app gefunden habe die mit 24 nicht gefunzt hätte.

bei 20 hab ich bspw. schon eine derbe verzögerung erlebt wenn ne app mal gekickt wird.

da 24 der mindestwert ist, und 30 aber eigentlich zuviel wenn man sich die werte vom droidx zum beispiel anschaut kann mans ja mal versuchen vielleicht auch nur mit 26 lol quasi ganz fein tunen.
vielleicht erleben wir ein unglaubliches performance battery wunder^^

games sind glaub ich der hauptgrund für viele die vmheap in die höhe zu treiben

Hin und wieder sind Begrenzungen für Anwendungen auch wichtig um rechtzeitig aufzuräumen
geb ich dir vollkommen recht.

Grundsätzlich kann ich mir kaum vorstellen, dass die Akkulaufzeit hier eine Rolle spielt - das ist vermutlich ähnlich wie mit dem übertakten - merken tue ich davon nichts. Gemessen habe ich allerdings auch nicht.

hmmm also meine performance und akkulaufzeit ist schon besser seitdem ich "übertaktet/undervolted" hab. wirklich gemessen hab ich sie aber auch nicht
 
Zuletzt bearbeitet von einem Moderator:
Ich bin mir relativ sicher, dass der GC seltener läuft mit 24MB als mit 32MB.

Das warten und "kicken" bei kleinerer VM-HS kann eigentlich nicht sein, da ja weniger da ist ;)

Wenn ein Programm mehr Speicher benötigt als der Heap da ist, bekommt es den nicht und es wird geschlossen. Nur in seltenen fällen kann hier der GC kommen und ausreichend Pages frei machen um dies zu retten. Grundsätzlich kann es passieren, dass bei größerer VM-HS der GC öfter läuft da alle Programme zusammen mehr HS haben als MEM da ist. Ich denke auch, dass genau dieser Vorgang oftmals zum FC und langen Wartezeiten führt.

Schnellere Anwendungen bei Geräten mit unter 384MB Ram hört sich sehr nach Hype an. Ich arbeite auch am PC oft mit speicherhungriegen Javaanwendungen und kenne nur ein Fall wo ein größerer Heap geholfen hat die Anwendung zu beschleunigen.

Tatsächlich kann ich, abgesehen von Kartenspielen, in Sachen Games nicht wirklich aus Erfahrung schöpfen und würde mich in diesem Spezialfall auch gerne eines Besseren belehren lassen!

Ich lasse gerne mein Kartenspiel meiner Wahl und Audible gleichzeitig laufen. Hinzu kommen hin und wieder Skype oder die Cam. Bisher ohne Probleme. Mit 32MB war schon des öfteren nach einem Telefonat das Kartenspiel geschlossen und ich durfte noch einmal anfangen.

Gruß
 
Das warten und "kicken" bei kleinerer VM-HS kann eigentlich nicht sein, da ja weniger da ist

EDIT: das der GC öfter im hintergrund läuft liegt afaik ebenfalls an dem zusammenspiel mit den minfree werten. (wenn wir von nur 1ner app reden würden würde ich dir recht geben)
das warten kommt daher das die cpu im hintergrund mit dem gc beschäftigt ist während man versucht eine neue app zu starten, wie klein man die heap size auch immer stellt, irgendwann kickt es ne alte app endgütig raus (was ja auch so sein soll) wenn man dann aber mehrere sachen macht oder ne neue starten will dauerts nochmal länger.

der grund warum sich das system mit weniger heap size reaktionsfreudiger zeigt ist das mehr apps oder zumindest mehr bruchteile davon noch im speicher sind weil einfach mehr von ihnen platz haben.

Grundsätzlich kann es passieren, dass bei größerer VM-HS der GC öfter läuft da alle Programme zusammen mehr HS haben als MEM da ist. Ich denke auch, dass genau dieser Vorgang oftmals zum FC und langen Wartezeiten führt.

ja bei großen VM Heaps bin ich mir nicht ganz sicher, allerdings wird das system von weniger anwendungen belegt da das ram management sie definitiv früher killen wird da schneller weniger speicher vorhanden ist. deswegen ist bei uns dann ja auch kein richtiges multitasking möglich.
(ich verwende übrigens noch CM6, hab aber gegen die meinung anderer mit CM7 auch die erfahrung gemacht das es gut mit einer heap von 24 läuft)

Schnellere Anwendungen bei Geräten mit unter 384MB Ram hört sich sehr nach Hype an. Ich arbeite auch am PC oft mit speicherhungriegen Javaanwendungen und kenne nur ein Fall wo ein größerer Heap geholfen hat die Anwendung zu beschleunigen.

es geht dabei ja nicht um schnellere apps, es geht darum das androids memory management das tut was es soll. was bei einer falsch eingestellten vm heap einfach entweder zu selten, oder zu oft der fall sein wird. was sich so oder so wiederum negativ auf die system performance auswirkt.

Wenn ein Programm mehr Speicher benötigt als der Heap da ist, bekommt es den nicht und es wird geschlossen. Nur in seltenen fällen kann hier der GC kommen und ausreichend Pages frei machen um dies zu retten.

das grundproblem das eine app die auf dem stein (bzw. auf 256mb ram) funktionieren soll wegen speichermangels geschlossen wird dürfte garnicht auftreten weil android rechtzeitig platz freischaufeln "sollte".
also liegt es (im fall von MS kompatiblen apps) entweder an schlechten apps oder an einem schlecht getweaktem system

Ich lasse gerne mein Kartenspiel meiner Wahl und Audible gleichzeitig laufen. Hinzu kommen hin und wieder Skype oder die Cam. Bisher ohne Probleme. Mit 32MB war schon des öfteren nach einem Telefonat das Kartenspiel geschlossen und ich durfte noch einmal anfangen.
wie gesagt hier bin ich absolut deiner meinung, mit >32 is multitasking auf dem stein nichtmehr so toll.
aber 32 ist nunmal ein default wert (und die sind ja da um sie zu tweaken^^), wenn der wert 24 bei CM wär, wären nutzer von geräten mit mehr speicher sicher auch nicht hundertpro glücklich damit.
 
Zuletzt bearbeitet von einem Moderator:
Ich denke auch, dass 24 ein guter wert für den stein ist, 32 scheint mir fürs multitasking zu viel. Ich persönlich stelle immer 24 ein, habe das bei cm6 und cm7 gemacht und es lief beidesmal deutlich besser.
 
Ich habe seit 2.2.1 ein Problem mit MOTONAV. (Laut Moto läuft Motonav auch mit 2.2.1 nicht mehr richtig)
Es kommt dabei immer wieder zu spontanten Reboots.
Könnte eine Erhöhung des Heaps hier vielleicht was bringen?
 
ich finde 42 sind ein guter wert :)
 
ich habe jetzt bei mir 24 eingestellt und das system reagiert subjektiv deutlich schneller als mit 32 oder 40.
 
rauke schrieb:
ich habe jetzt bei mir 24 eingestellt und das system reagiert subjektiv deutlich schneller als mit 32 oder 40.

geht mir auch so
 
christian7301 schrieb:
Gilt mir diese Empfehlung?

warum nicht? versuchs einfach mal. bei so großen apps könnte es helfen.

sent from my current location
 
justanordinarydude schrieb:
warum nicht? versuchs einfach mal. bei so großen apps könnte es helfen.

sent from my current location

Danke, werde ich machen!
 

Ähnliche Themen

A
Antworten
4
Aufrufe
1.915
-FuFu-
-FuFu-
T
Antworten
30
Aufrufe
6.285
Loader009
L
Noogieman
Antworten
2
Aufrufe
2.078
pulpo81
P
Zurück
Oben Unten