Anyone know (with our phones running 2.2) what the optimal heap size should be? The leaked 2.2 came with 24m preset. Some ROMs run 32m. Bigger always seems better, but I've been reading other sites/forums and get conflicting thoughts.
That's why I thought I'd ask here.
I ran Linpack with both and average about 37.5 - 37.9 with either 24m or 32m.
I ran a few test increasing it to 48m and seen a decrease in performance. Bigger does not me better. I can not speak for anyone else but the best results i've seen was on 32m
theoneownz said:
I ran a few test increasing it to 48m and seen a decrease in performance. Bigger does not me better. I can not speak for anyone else but the best results i've seen was on 32m
Click to expand...
Click to collapse
same here, 32 seems to be the optimal size for me, I didn't see any difference with linpack but my quadrant went up when I set the heapsize from 24 to 32
Is there a way to patch the original leaked 2.2 to run its vm heap size at 32m?
I have my vm heap at 40 amd it runs smooth
Sent from my ADR6300 using XDA App
xvenom89 said:
Is there a way to patch the original leaked 2.2 to run its vm heap size at 32m?
Click to expand...
Click to collapse
Like to find this out myself. I've seen that this can be modified in the Cyanogen rom using Rom Manager, but not sure how this can be done via stock 2.2 rom.
I am by no means "good" at android yet, but im pretty sure there is an option to change the vm heapsize in build.prop in the /system directory. Just use adb to pull the one on there and then push the edited one (that u edit urself) to the phone. Also from what i can remember reading the heapsize basically is just how much ram/memory an app is allowed to use before android has to start "trash collecting" or "tidy up" the app usage. Setting it low will give the best linpack scores i think, but it will completely screw up regular app usage. Best to keep it at default to 32 imo. Setting it higher really wont do anything i dont think except maybe boost ur quadrant score but that may not transfer over to real app usage. My .1 cent
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
That is what u would be editing in your build.prop
chris61292 said:
I am by no means "good" at android yet, but im pretty sure there is an option to change the vm heapsize in build.prop in the /system directory. Just use adb to pull the one on there and then push the edited one (that u edit urself) to the phone. Also from what i can remember reading the heapsize basically is just how much ram/memory an app is allowed to use before android has to start "trash collecting" or "tidy up" the app usage. Setting it low will give the best linpack scores i think, but it will completely screw up regular app usage. Best to keep it at default to 32 imo. Setting it higher really wont do anything i dont think except maybe boost ur quadrant score but that may not transfer over to real app usage. My .1 cent
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
That is what u would be editing in your build.prop
Click to expand...
Click to collapse
Modified and updated.
I had a feeling it was the build.prop file I needed to edit.
Thank you sir!
But remember that bigger is not alwaus better. Im ising 40m and it is not better or worse than 32 or 24.:although i did notice some nice difference in the general speed of the os itself
chris61292 said:
I am by no means "good" at android yet, but im pretty sure there is an option to change the vm heapsize in build.prop in the /system directory. Just use adb to pull the one on there and then push the edited one (that u edit urself) to the phone. Also from what i can remember reading the heapsize basically is just how much ram/memory an app is allowed to use before android has to start "trash collecting" or "tidy up" the app usage. Setting it low will give the best linpack scores i think, but it will completely screw up regular app usage. Best to keep it at default to 32 imo. Setting it higher really wont do anything i dont think except maybe boost ur quadrant score but that may not transfer over to real app usage. My .1 cent
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
That is what u would be editing in your build.prop
Click to expand...
Click to collapse
Sent from my ADR6300 using XDA App
chris61292 said:
I am by no means "good" at android yet, but im pretty sure there is an option to change the vm heapsize in build.prop in the /system directory. Just use adb to pull the one on there and then push the edited one (that u edit urself) to the phone. Also from what i can remember reading the heapsize basically is just how much ram/memory an app is allowed to use before android has to start "trash collecting" or "tidy up" the app usage. Setting it low will give the best linpack scores i think, but it will completely screw up regular app usage. Best to keep it at default to 32 imo. Setting it higher really wont do anything i dont think except maybe boost ur quadrant score but that may not transfer over to real app usage. My .1 cent
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
That is what u would be editing in your build.prop
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=803470
chris61292 said:
I am by no means "good" at android yet, but im pretty sure there is an option to change the vm heapsize in build.prop in the /system directory. Just use adb to pull the one on there and then push the edited one (that u edit urself) to the phone. Also from what i can remember reading the heapsize basically is just how much ram/memory an app is allowed to use before android has to start "trash collecting" or "tidy up" the app usage. Setting it low will give the best linpack scores i think, but it will completely screw up regular app usage. Best to keep it at default to 32 imo. Setting it higher really wont do anything i dont think except maybe boost ur quadrant score but that may not transfer over to real app usage. My .1 cent
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
That is what u would be editing in your build.prop
Click to expand...
Click to collapse
If you use Root Explorer (which is an invaluable app, IMO), then you don't even have to go through the trouble of adb push and pull. With RE, you an simply just edit the file and be done with it.
Does anyone else get that issue where the web browser closes for no reason (no error or anything) when heap size is set to 24m? Only when I switched to Sadowrom and changed the heap to 32m did it stop this annoying issue that was present in every rom that I've tried. It mostly happened on heavy script/flash websites so I assumed it was a memory issue (happened a lot on this forum as well). 32m should really be default, this seems like a common issue from what I've read.
blakeem said:
Does anyone else get that issue where the web browser closes for no reason (no error or anything) when heap size is set to 24m? Only when I switched to Sadowrom and changed the heap to 32m did it stop this annoying issue that was present in every rom that I've tried. It mostly happened on heavy script/flash websites so I assumed it was a memory issue (happened a lot on this forum as well). 32m should really be default, this seems like a common issue from what I've read.
Click to expand...
Click to collapse
From what I've seen, the common denominator seems to be that the majority of phones experiencing this are overclocked. Some phones can handle it whereas others cannot. My last Inc would do this if oc'd to 1.15 but was fine at lower speeds. My current Inc rarely does this even when pushed to 1.19.
najaboy said:
From what I've seen, the common denominator seems to be that the majority of phones experiencing this are overclocked. Some phones can handle it whereas others cannot. My last Inc would do this if oc'd to 1.15 but was fine at lower speeds. My current Inc rarely does this even when pushed to 1.19.
Click to expand...
Click to collapse
Mine did it with 100% stock 2.1 and 2.2 w/ no root or overclocking and was actually the main thing that motivated me to install roms (my work bought me the phone so I was hesitant).
All kinds of apps close if I overclock it to unstable levels (AOSP goes unstable much more dramatic for me at 1.15, sense is mostly stable up to 1.19) but I believe this is a different issue. Bits are lost so apps go boom, much like the artifacts when I overclock my graphics card too far. Overclocking is the issue when other apps close as well but with the lower heap size only my browser closes after many days of up time without any other issues. I have no issues since heap has been 32m, it would happen daily at 24m.
There is one website that can still bring it down however, that is viewing the full google images page. It seems to have a recursive issue where things load over and over again and the browser eventually vanishes. I can load 500 page pdf files and run stress tests all day and never get them to close or error so I'm pretty sure it's a browser specific issue (does it in all other browsers that I've tried as well).
martino2k6 said:
http://forum.xda-developers.com/showthread.php?t=803470
Click to expand...
Click to collapse
thank you!
I changed the build.prop, but left the 'm' off at the end of the line, now it won't boot up. I can adb shell into it, adb pull, but su doesn't work, segfaults, can't push the file back to /system. How do I fix it??
Related
EDIT: These settings don't seem to be read by the lowmemorykiller process, so they have no effect. But the app Autokiller modifies the settings in /sys/module/lowmemorykiller/parameters/minfree and that one works!
Hey guys, I just noticed this thread and it's very interesting.
http://forum.xda-developers.com/showthread.php?t=622666
Android has its own low memory task killer, and it can be configured. I checked the defaults for my JPC Froyo firmware, and it was set a bit low, meaning processes are not killed as soon as they should be.
I also think I've found a new way to configure those options:
I modified my /system/build.prop file and added the following lines.
# tune the lowmemorykiller
ro.FOREGROUND_APP_MEM=5120
ro.VISIBLE_APP_MEM=8192
ro.SECONDARY_SERVER_MEM=12288
ro.BACKUP_APP_MEM=12288
ro.HOME_APP_MEM=12288
ro.HIDDEN_APP_MEM=20480
ro.CONTENT_PROVIDER_MEM=22528
ro.EMPTY_APP_MEM=24576
Reboot for it to take effect.
These values are twice my original ones. You can check current values by doing a "getprop".
NOTE that these values are in PAGES (4K). So 24567 pages = 98,304 KBytes.
Strangely the /sys/module/lowmemorykiller/parameters/minfree values are not changed. But I think the lowmemorykiller might be reading the prop values directly. I'm running many programs now trying to hit the limit and see if it takes effect.
EDIT: It seems to be working! I can run many many apps and the phone remains responsive. Unused apps are killed as needed. Check out the screenshots below:
Is this Froyo specific or does it also apply to Eclair?
Edit: Never mind
Isn't this pretty old news?
Aren't there are apps in the Market for this (AutoKiller, MinFreeMgr)?
I guess if you know precisely the best settings for your own phone, putting them in a startup script makes sense. I didn't realize build.prop could be used to set things like that.
distortedloop said:
Isn't this pretty old news?
Aren't there are apps in the Market for this (AutoKiller, MinFreeMgr)?
I guess if you know precisely the best settings for your own phone, putting them in a startup script makes sense. I didn't realize build.prop could be used to set things like that.
Click to expand...
Click to collapse
MinFreeMgr tries to do the same thing but by editing a different file which doesn't stay on reboot. This build.prop edit is a new finding, and it seems to work. I think it could be a better solution as it stays after a reboot. The difference between this and other Auto Task Killers is that this is using Android's built-in memory management mechanism which is much smarter than any external task killer can be.
So far it works really well!
Can we convert this into a workable program?
Very interesting, will give it try.
hardcore said:
MinFreeMgr tries to do the same thing but by editing a different file which doesn't stay on reboot. This build.prop edit is a new finding, and it seems to work. I think it could be a better solution as it stays after a reboot. The difference between this and other Auto Task Killers is that this is using Android's built-in memory management mechanism which is much smarter than any external task killer can be.
So far it works really well!
Click to expand...
Click to collapse
Yeah, I acknowledged the build.prop was interesting, very interesting, actually. I wonder if you could set other parameters in there that some of the modders are throwing into init scripts and/or small apps.
For clarification, the two Market-available apps I mentioned (AutoKiller, MinFreeMgr), both do the exact same thing you're talking about. AutoKiller is poorly named, as it's not a task killer per se, it merely modifies on the fly the settings you're talking about here; same with MinFreeMgr. Both can be set to take affect at startup/reboot. Advantage, can be changed on the fly without reboot, disadvantage, another app to load during reboot.
Thanks.
distortedloop said:
For clarification, the two Market-available apps I mentioned (AutoKiller, MinFreeMgr), both do the exact same thing you're talking about. AutoKiller is poorly named, as it's not a task killer per se, it merely modifies on the fly the settings you're talking about here; same with MinFreeMgr. Both can be set to take affect at startup/reboot. Advantage, can be changed on the fly without reboot, disadvantage, another app to load during reboot.
Click to expand...
Click to collapse
Ah, thanks for clarifying that. I discovered those values when I did a getprop. The values I posted above (2x default) work okay. But now I'm trying slightly less aggressive values (1.5x) to see what might be the optimum - too much free RAM is also a waste.
By the way, what task manager is that your pics are of? Looks like the Samsung Task Manager, except the RAM tab. On mine, that tab's Summary and does not give the same info as yours. Mine's unchanged on the various firmwares I have used JG1, JG5, JM1, JM5, JM6, JH1, JM7...
distortedloop said:
By the way, what task manager is that your pics are of? Looks like the Samsung Task Manager, except the RAM tab. On mine, that tab's Summary and does not give the same info as yours. Mine's unchanged on the various firmwares I have used JG1, JG5, JM1, JM5, JM6, JH1, JM7...
Click to expand...
Click to collapse
You're right. Its the JPC Task Manager. It has those extra options to clear the memory. I don't use them now though.
With Eclair I have 326MB ram. Froyo has less just 304.
And after we speak for galaxy lag. I thing it is an android lag because the system to start cut ram from frozen apps and to give at the new application they try to open, the free ram must be 48mb.
Very less for the UI.
I am not happy. We let WM so as to don't need fixes and custom rom. And we have other problems.
I will give it a try. Already modified my build.prop and un-installed Autokiller. Will check for the next few days.
P/S: Probably due to placebo effect, but it feels more responsive.
If it works, this is a good hack!
distortedloop said:
By the way, what task manager is that your pics are of? Looks like the Samsung Task Manager, except the RAM tab. On mine, that tab's Summary and does not give the same info as yours. Mine's unchanged on the various firmwares I have used JG1, JG5, JM1, JM5, JM6, JH1, JM7...
Click to expand...
Click to collapse
That's the froyo task manager, which can be found in the earlier froyo (xxjp3) release as well.
If you want, i can attach this apk (either odexed or deodex, you pick) for you to try on eclair.
hardcore said:
Hey guys, I just noticed this thread and it's very interesting.
http://forum.xda-developers.com/showthread.php?t=622666
Android has its own low memory task killer, and it can be configured. I checked the defaults for my JPC Froyo firmware, and it was set a bit low, meaning processes are not killed as soon as they should be.
I also think I've found a new way to configure those options:
I modified my build.prop file and added the following lines.
# tune the lowmemorykiller
ro.FOREGROUND_APP_MEM=5120
ro.VISIBLE_APP_MEM=8192
ro.SECONDARY_SERVER_MEM=12288
ro.BACKUP_APP_MEM=12288
ro.HOME_APP_MEM=12288
ro.HIDDEN_APP_MEM=20480
ro.CONTENT_PROVIDER_MEM=22528
ro.EMPTY_APP_MEM=24576
Click to expand...
Click to collapse
Hey, I was thinking about this, and I started to do some research and found that for Froyo, other devices are using these as parameters:
ro.FOREGROUND_APP_MEM 1536
ro.VISIBLE_APP_MEM 2048
ro.SECONDARY_SERVER_MEM 4096
ro.BACKUP_APP_MEM 4096
ro.HOME_APP_MEM 1536
ro.HIDDEN_APP_MEM 5120
ro.CONTENT_PROVIDER_MEM 8192
ro.EMPTY_APP_MEM 10240
I'm just wondering if we should be increasing the memory sizes or decreasing them?? Maybe do a combination of both?? I gotta do more research, find out how each attribute behaves, and get more info before editing this stuff.
YG007 said:
Hey, I was thinking about this, and I started to do some research and found that for Froyo, other devices are using these as parameters:
ro.FOREGROUND_APP_MEM 1536
ro.VISIBLE_APP_MEM 2048
ro.SECONDARY_SERVER_MEM 4096
ro.BACKUP_APP_MEM 4096
ro.HOME_APP_MEM 1536
ro.HIDDEN_APP_MEM 5120
ro.CONTENT_PROVIDER_MEM 8192
ro.EMPTY_APP_MEM 10240
I'm just wondering if we should be increasing the memory sizes or decreasing them?? Maybe do a combination of both?? I gotta do more research, find out how each attribute behaves, and get more info before editing this stuff.
Click to expand...
Click to collapse
I think increasing is better if you want apps to be auto killed. The default values (for JPC at least) are half of what I suggested. And it didn't seem to be aggressive enough for the SGS.
hardcore said:
I think increasing is better if you want apps to be auto killed. The default values (for JPC at least) are half of what I suggested. And it didn't seem to be aggressive enough for the SGS.
Click to expand...
Click to collapse
Just a side topic, saw your CSC is OLBJG4, did you manage to flash and got it configured automatically, or that *#272*HHMM# still does not work, and you have to set the apn manually?
hardcore said:
But now I'm trying slightly less aggressive values (1.5x) to see what might be the optimum - too much free RAM is also a waste.
Click to expand...
Click to collapse
That's the mantra in linux "free memory is wasted memory."
I first saw this stuff discussed here. Probably nothing you haven't figured out yet.
I think the settings for any individual are going to vary; there is no set answer, too much of variable in how you use your phone and what apps you use, etc.
You might check out "AutoKiller", it's free, and has some presets, along with ability to roll your own settings. I'd play with it until I found the numbers I liked best, then you could bake them into your build.prop. That would save you the slight hassle of editing and rebooting.
You can also just echo them from the terminal app, but I'm sure you already knew that.
But for those who don't, here's a sample from the above linked article:
Code:
su
echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Also, while you're playing with settings, have you also looked at changing the i/o scheduler. Lots of debate over what's best. Again, I think it just depends on how you as an individual use your phone...
g00ndu said:
Just a side topic, saw your CSC is OLBJG4, did you manage to flash and got it configured automatically, or that *#272*HHMM# still does not work, and you have to set the apn manually?
Click to expand...
Click to collapse
I sortof hacked it into my /system folder manually. Just need to replace some files there. Auto APN does work. Maybe I'll write up a procedure when I'm more sure of it.
Interesting. Keep up the good work!
hmm...what is the difference between setting it in build.prop vs setting it in autokiller?
Hi i found an app called auto killer memory which ive been running for a while. this app has worked wonders for my wilderbeast, its on fire. so ive been tampering alot with things but this seems to have stabalised my phone loads. presets i set to lost, enabled advance mode,apply at boot,ticked all system tweaks and of course when promted enabled super user. my phone is now running sweet and battery has improved too. i dont know if this makes any sense but i have noticed a difference. whoop whoop. am i over optimistic that this works the same as the v6 super charger/juwes ram optimiser ???
Ok I've ammended my settings within this app after doing some research And in memory values I'm now running at 6/10/16/100/120/160 to keep my phone running snappppppy. To explain the values in brief...... if free memory goes below 160mb my phone starts to kill empty apps etc etc as free memory goes below next value the phone starts to kill corresponding apps. Kind of makes sense to me now. Ok I know my settings makes the phone kill more frequently but its damn snappy now,and it can lower the oom settings by long pressing the app in processes section you wish to lower and choosing lower oom. Lowering the oom basically gives the app less chance of being killed.
Personally I haven't had a low memory situation since I rooted and installed cm7, the app your talking about I have installed after reading one of your other posts about it, I presume that it would work the same way as juwes after setting the low memory values, I don't use those settings with it though as I have juwes script installed, the other tweaks seem fine but again I think I had some of them covered from editing my build.prop (still have work to do on that though) and a few other little things, I can't knock this app though as it does seem to have made my battery last a bit longer since installing yesterday, I'd personally rather change the settings myself than have yet another app doing it for me but until I figure which setting seems to be helping my battery out I'll keep it installed.
A couple of other apps which might help you keep it smooth,
Autostarts- I swear by this app its one of my best buys from the market, why use a task killer when you can just stop the app starting in the first place??
Fast reboot pro- after time apps hold memory which they don't really need, hit this and it'll quickly reboot everything (unless you tell it to leave something alone) freeing up spare ram.
Sent from my HTC Wildfire using xda premium
Cheers for info,really happy with this app at the moment.by the sounds of things its doing similar job to other script mods,which I can't get working cos of s - off issue. Posted this for s on users benefit. Hope it helps others.
Edit my settings. Read 1st post.
sent from my wilderbeast/buzz
The only problems I see with having higher settings are if it closes something you use regular it'll be slower to open that app, I'd rather keep them set low and have apps open quickly.
Sent from my HTC Wildfire using xda premium
Scratch0805 said:
The only problems I see with having higher settings are if it closes something you use regular it'll be slower to open that app, I'd rather keep them set low and have apps open quickly.
Sent from my HTC Wildfire using xda premium
Click to expand...
Click to collapse
I agree but this app lets you temporary lower the oom level for apps,so I just lower oom on most important. Long click on process or service and to lower.
sent from my wilderbeast/buzz
Does it?..........I didn't spot that nice find!!
Sent from my HTC Wildfire using xda premium
Yep,long click app in service or process then choose to lower oom.it resets if you reboot so get your settings desired then leave by pressing home button.
sent from my wilderbeast:buzz
whats up with these settings for the pages? what do these settings change?
atm i have these settings:
2560
4096
25600
30720
40960
gozzaa said:
whats up with these settings for the pages? what do these settings change?
atm i have these settings:
2560
4096
25600
30720
40960
Click to expand...
Click to collapse
Change the view from pages to mb and these are the values when it will start killing processes etc. Ie. When your memory gets to the amount your phone starts freeing up starting with the highest setting (empty apps)
Its all explained above,just that you have the pages view instead of mbs.
Quote " its healthy to have enemies, it means you've stood up for something you believe in "
ahh the pagesettings are the same as the MB ones?
i thought its two different things
thanks for the explanation!
btw. do you still use the same settings?
Yes to this day I still use this app even though I'm now s-off with the settings I posted,I will just double check and ammend if needed on 1st post.
" once its gone,its GONE."
slymobi said:
am i over optimistic that this works the same as the v6 super charger/juwes ram optimiser ???
Click to expand...
Click to collapse
I used to use that too and I felt some differance too but I think you have to open the program every boot. But some told me that it isn't just powerful as Supercharger so I deleted the optimiser and tried Supercharged and got a bootloop instead. I didn't get it to work but I believe that Supercharger is a better solution.
zephyri-xr said:
I used to use that too and I felt some differance too but I think you have to open the program every boot. But some told me that it isn't just powerful as Supercharger so I deleted the optimiser and tried Supercharged and got a bootloop instead. I didn't get it to work but I believe that Supercharger is a better solution.
Click to expand...
Click to collapse
i tried supercharger and juuwes but had issues which i think were specific to me but one of the issues was bootlooping from supercharger as well as other things. im not saying one is better than the other but as you and myself had issues with one of the mods then its an alternative for others to use. i prefer this as you get to control the settings and mods yourself from the app. also this is available for s-on whilst the others i believe need s-off.
zephyri-xr said:
I used to use that too and I felt some differance too but I think you have to open the program every boot. But some told me that it isn't just powerful as Supercharger so I deleted the optimiser and tried Supercharged and got a bootloop instead. I didn't get it to work but I believe that Supercharger is a better solution.
Click to expand...
Click to collapse
I got a boot loop from supercharger. I had to wipe my phone and start again from an RUU as all my previous backups became corrupted. Nightmare. TBH in the few days that it did work, i saw/felt no difference.
Using CM_7.1.0.1 probably wouldnt advise to use the supercharge, CM_7 minfree values are set to a pretty good level to keep things in order i think
slymobi said:
Hi i found an app called auto killer memory which ive been running for a while. this app has worked wonders for my wilderbeast, its on fire. so ive been tampering alot with things but this seems to have stabalised my phone loads. presets i set to lost, enabled advance mode,apply at boot,ticked all system tweaks and of course when promted enabled super user. my phone is now running sweet and battery has improved too. i dont know if this makes any sense but i have noticed a difference. whoop whoop. am i over optimistic that this works the same as the v6 super charger/juwes ram optimiser ???
Ok I've ammended my settings within this app after doing some research And in memory values I'm now running at 6/10/16/100/120/160 to keep my phone running snappppppy. To explain the values in brief...... if free memory goes below 160mb my phone starts to kill empty apps etc etc as free memory goes below next value the phone starts to kill corresponding apps. Kind of makes sense to me now. Ok I know my settings makes the phone kill more frequently but its damn snappy now,and it can lower the oom settings by long pressing the app in processes section you wish to lower and choosing lower oom. Lowering the oom basically gives the app less chance of being killed.
Click to expand...
Click to collapse
I have tried supercharge script and does make phone smooth. Also Ive use ram manager new app and that too made phone smooth. But this app (Pro) is so far great. I tried out your settings for now to see if it suits me and had the app for an hour and the phone is very snappy and smooth (which is most important to me). I hope there is a slight battery improvement that many have said on the net but will test more and will leave feed back. A big thx m8!
no probs mate, like i said i have tried the lot and this one for me is really good and you get to be the controller lol.the only drawback i have noticed is that it takes a little longer for the phone to boot after a reboot but !!!!! im ok with that.
LMFAO looks like I didn't pay enough attention... I've used a lot of tweaks already to make my Willy faster, more snappy and stable but to be honest nothing gave it such a boost like that
BTW: are you still using the settings of the op?
Holy crap, I've read that really often here and elsewhere but it's the first it applies to myself: feels like a new phone
eventcom said:
LMFAO looks like I didn't pay enough attention... I've used a lot of tweaks already to make my Willy faster, more snappy and stable but to be honest nothing gave it such a boost like that
BTW: are you still using the settings of the op?
Holy crap, I've read that really often here and elsewhere but it's the first it applies to myself: feels like a new phone
Click to expand...
Click to collapse
I use aggressive setting mostly, all advanced tweaks except sdcard boost one as this bumps read ahead up to 2048, just my preference you might prefer 2048.
Say oooh la la
slymobi said:
I use aggressive setting mostly, all advanced tweaks except sdcard boost one as this bumps read ahead up to 2048, just my preference you might prefer 2048
Click to expand...
Click to collapse
I see. I just have to sort things out now. Regarding the SD card read - I have it already done by sdbooster (@2048) - I'm at a point where I should make a documentation to stay on track and to avoid double tweaks lol.
I'm also very interested into scratch's build.prop lol (guess that would help to drop even more tweaks). Thx again - I've not forgotten about your tip re. AMO - just shifted it too far lol.
As the title state. And please get it together & keep it clean, as this is kinda important to all.
Any help & explaination would be much apprecited.
Regards,
Sdojoin
I used to mess wit this on the X10, and did find better values. But for the Xperia Play, at least on CM10, any extra or changed flags either causes worse performance or FC's.
The defaults I use are:
Code:
dalvik.vm.dexopt-flags=m=y
Which means "Map registration = yes" (this should always be on) and everything else at default (what the ROM wants to do).
90% of what you need to know (and what is safe to experiment with) can be found in the DalvikVM documentation. Give it a good read.
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Thanks. But i was wondering if mybe we can "force" the system/rom to optimize the dalvik.vm each time we use it.
Example;
Code:
dalvik.vm.dexopt-flag=o=y,m=y(optimize=yes, register map=yes)
Or
Code:
dalvik.vm.dexopt-flag=o=v,m=y(optimize=verify,register map=yes)
Will it make any diff?? I know it'll use more ram than usual, but will it increase performence??
Regards,
Sdojoin
o=v (-Xdexopt:verified) is the default, as is v=a (-Xverify:all). This means that only opts that are verified will be optimized (cached to dex files). Unverified code will not be optimized.
Disabling verification will make dalvik-generation faster, but it is less safe and also 0% faster once the dalvik-cache is generated. Apparently it has the possibility of decreasing RAM usage at the expense of higher IO or CPU cycles (which wouldn't be bad, since RAM is the main limiting hardware on Xperia 2011 devices) but I never noticed any difference.
The only real change you can make there is o=a, which means that it will optimize *all* dalvik opts - even those that fail verification. In the case of custom ROM's, this usually results in constant FC's and even reboots - and can even make the system slower because some classes are intentionally made to fail verification when, in the development process that they were found to have overhead in dalvik-cache reading making the unverified cache slower than just reading reading the dalvik (compiled Java code) directly. This is usually the case with simple Java methods that are heavily dynamic and rarely used (e.g. on a service startup).
Another option can be v=n o=a which means to verify nothing and optimize everything (potentially the fastest but also unsafest).
With all this said, I have not tried messing with these things since Gingerbread. All I can say is, experiment with these flags. Measure the size of dalvik-cache, the time it takes to generate, and the time it takes to load a large dalvik app (look for an app/game that has a very large DEX file in dalvik-cache, measure different parts of the app/game loading sections since some parts might be native instead of dalvik/java).
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
sdojoin said:
How exactly do i do that test??
Fyi, i already tried the v=n,o=a sett. It kinda denied su perm or mybe unroot my device. Coz i cant get any root app running & i hav to revert it back via flashable .zip. But like u said, its un-safe to use.
In-conclusion, "it can increase our perf & decrease it at the same time.". Erm...
Oh yeah, is it posible if i were to flag it like this??
Code:
dalvik.vm.dexopt-flag=m=o=y(map registration=Xdexopt=yes)
Just curious.
Regards,
Sdojoin
Click to expand...
Click to collapse
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
CosmicDan said:
Nah, that makes no sense.
Read through this thread: http://forum.xda-developers.com/showthread.php?t=1622433
Click to expand...
Click to collapse
Already read that actually.. I've already search & read through the web bout this still cant find any straight answer bout this. But then again there aren't any straight answer bout this, is there??
Another thing i would like to ask is bout vm.heapsize. Correct me if i'm wrong, the default value for all device is 32m, right?? And all my search state that 48m is the best value for both batt drain & perf. What do u think of that?? I really believe Play can do more & perform better in any case of situation. Dont matter either on stock or custom. Just need the right tweakin'.:fingers-crossed:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
Click to expand...
Click to collapse
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Hmm... Quite a mouthfull. Imma try & digest it slowly just so i could grasp everything properly.
A side Q, the 40m example u gav, does that really help?? I'm on GB btw. Only went to ics or jb when i got free time to test.
Do u recommend that example to be use or do u hav any other recommendation that would probably help me & other that read this thread??
Regards,
Sdojoin
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Experiment and see as long as you make backups, nothing can possiblii go wrong.
Sent from Xperia Play (R800a) with Tapatalk
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Right on. Thanks for ur time & for sharing ur experience & everything.
Salute.
Regards,
Sdojoin
No problem. Let me know if you find anything interesting. But you are on GB and I'm on JB, still I don't have much time to mess with this stuff - especially now that my linux machine is back in action
Re: [Q][Disqus] "Dalvik.vm.dexopt-flag=???" - What are the best for performence
Woo.. Guess we can expect smething new from ya?? And i think i found smthing thats kinda weird or mybe interesting. After i disable the bytecode verifier, any heapsize that i put on build.prop dosent stick. And when i run this code on terminal,
Code:
getprop dalvik.vm.heapsize
It always came up with the same value. So i decided to use that value instead. I dont know if its the best value or not. But it does shows slight improvement. I havent try any games yet. Hopefully it perform a bit better than be4.
Regards,
Sdojoin
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
CosmicDan said:
Well that first link I posted explains pretty much everything about the dalvik flags, and that thread I posted last is a good experiment for learning purposes. If it doesn't make sense I guess you need to know more about the Android technicals. But really, I think you can't wrap your head around it for one simple reason - there is no magical dalvik setting that will make the device faster. There is no "hidden setting" or "something Sony/FXP forgot to try" - the dalvik settings are fine, and while changing them may slightly increase performance in *some* cases, it will almost always reduce reliable and performance in other cases.
About dalvik heapsize:
In summary - heapsize = memory an app can consume before Android starts cleaning/pruning the app's memory for data that isn't in use. Lowering it to e.g. 40m can increase performance a bit but some games fail to load (because the OS starts GC when the app has not finished using the heap it requires; and also because so many game developers out there are lazy and don't do threaded asset loading properly)
Click to expand...
Click to collapse
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
xxLeoxx93 said:
Ther is one thing i don't understand: the default values of the Nexus 7 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=384m
Especially the heapsize seems to be very high.
The defauklt settings of my Galaxy Note with CM10.1 are:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
So they are much lower values. Bothe devices have 1Gb of Ram.
Some people say higher=better, some say lower=better and I'm really confused now.
What are the "perfect" values for the Galaxy note (1GB Ram) or Note 2 (2GB Ram) ?
I hope somone can explain me these things :fingers-crossed:
Click to expand...
Click to collapse
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
CosmicDan said:
Hey,
These have seemed to improve performance (mainly boot time and app loading) on Gingerbread. They are set in new Turbo UI Classic ROM, give them a try.
Code:
# was m=y
dalvik.vm.dexopt-flags=m=y,v=n,o=v,u=n
TBH, I really don't know a lot about how the dalvik flags tie together. But this seems to work well and stable.
Click to expand...
Click to collapse
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
sewer56lol said:
There never exist "perfect values for dalvik".
It is how you want to allocate memory.
1. VM Heap Size is max Memory per one ram heal that can be given to an app.
2. Heapstartsize is the minimum size for a dalvik ram heap.
3. HeapGrowthLimit is a value for "normal" VM heaps, I reccomend setting VM heap size large and then HeapGrowthLimit at a good value.
Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse
No it's not. All the heapsize parameters are to do with GC, they have nothing to do with "how much memory" dalvik tasks will use but determine barriers/zones for garbage collection.
Besides, if you read the therad you'd see that this has nothing to do with what we're talking about. We're talking on *flags*, heap parameters should NEVER be changed and will only make device unreliable.
EDIT: Read documentation before repeating what others say on the internet - http://show.docjava.com/posterous/file/2012/12/10222640-The_Dalvik_Virtual_Machine.pdf
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
Hmm fair enough. Well I've only ever seen m=y on any ROM, stock or custom or otherwise (as long as it hasn't been screwed up by some idiot chef). So maybe it's just a case as most so-called tweaks - what it comes with is what it's designed to work with.
Perhaps with the Qualcomm-accelerated Dalvik blobs (I posted it a while back, check my threads) there will be different results.
sdojoin said:
Already tried n went back to m=y. It kinda hung up on some app that make'em fc. A diff sequence mybe??
Regards,
Sdojoin
Click to expand...
Click to collapse
have you delete dalvikcache and reboot on every change?
mpjoe2000 said:
have you delete dalvikcache and reboot on every change?
Click to expand...
Click to collapse
Same.. Thats y its weird.
@CosmicDan - can u giv the thread link?? Thx
Regards,
Sdojoin
I'm running the Pacman ROM and it runs pretty good, but I want to maximize performance. I have some questions that I hope one of you will answer.
1. Is the Heapsize set with the ROM that gets flashed, or is it internal? What number is it set at, and what number do I want it at?
2. I am S-OFF and I'd like to know more about activating the a2sd Jit. Unfortunately there isn't much info for the Evo on this. What is DalvikDM Jit and what does it do?
3. I'm looking at the Low Memory Killer Commands on the a2sd help, but I'm not sure if I need to adjust anything here because I've done this with Android Tuner and if screws everything up. I'm probably doing it wrong. Can you tell me about this and where I might like to set it at with a2sd.
Thanks for reading my post.
Sleepycloud said:
I'm running the Pacman ROM and it runs pretty good, but I want to maximize performance. I have some questions that I hope one of you will answer.
1. Is the Heapsize set with the ROM that gets flashed, or is it internal? What number is it set at, and what number do I want it at?
2. I am S-OFF and I'd like to know more about activating the a2sd Jit. Unfortunately there isn't much info for the Evo on this. What is DalvikDM Jit and what does it do?
3. I'm looking at the Low Memory Killer Commands on the a2sd help, but I'm not sure if I need to adjust anything here because I've done this with Android Tuner and if screws everything up. I'm probably doing it wrong. Can you tell me about this and where I might like to set it at with a2sd.
Thanks for reading my post.
Click to expand...
Click to collapse
1. Is the Heapsize set with the ROM that gets flashed, or is it internal? What number is it set at, and what number do I want it at?
At runtime, the heap grows dynamically in size as the Dalvik VM requests system memory from the operating system. The Dalvik VM typically starts by allocating a relatively small heap. Then after each GC run it checks to see how much free heap memory there is. If the ratio of free heap to total heap is too small, the Dalvik VM will then add more memory to the heap (up to the maximum configured heap size).
That being said, the reason why you are not seeing "24 mb" on your DDMS screen is because the heap hasn't grown to its maximum size. This allows Android to make good use of the already small amount of memory that is available on handheld devices.
As for why your application is crashing on the emulator and not your phone, that does seem odd (are you sure the numbers are correct?). You should keep in mind, however, that memory is managed dynamically and that total memory utilization is determined based on a number of external factors (the speed/frequency at which garbage collection is performed, etc.).
Finally, for the reasons I mentioned above, it would be difficult to say for sure how well your application manages memory based on the single line of information you provided above. We'd really need to see some of your code. OutOfMemoryErrors are definitely worth worrying about, however, so I'd definitely look into your application's memory usage. One thing you might consider is to sample your bitmap images at runtime with calls to inSampleSize using the BitmapFactory class. This can help reduce the amount of memory required to load your drawable bitmaps. Either that or you could reduce the resolution of your drawables (although 20 kb each sounds fine to me).
Click to expand...
Click to collapse
2. I am S-OFF and I'd like to know more about activating the a2sd Jit. Unfortunately there isn't much info for the Evo on this. What is DalvikDM Jit and what does it do?http://android-developers.blogspot.com/2010/05/dalvik-jit.html
Diablo67 said:
1. Is the Heapsize set with the ROM that gets flashed, or is it internal? What number is it set at, and what number do I want it at?
2. I am S-OFF and I'd like to know more about activating the a2sd Jit. Unfortunately there isn't much info for the Evo on this. What is DalvikDM Jit and what does it do?http://android-developers.blogspot.com/2010/05/dalvik-jit.html
Click to expand...
Click to collapse
Now I understand why it's sometimes said to "let the ROM settle in for 15 minutes before you dig in," and "It gets faster after a day." Some previous versions of Jit "warm up to speed", but Dalvik Jit is almost instantaneous in response to a given command.
Hi,
I own a D855-16GB (the one with 2GB of RAM). I've tried stock ROM and Fulmics (1~5) and the phone keeps killing background apps, being something very annoying.
It was suggested in another post here (for KitKat) to change the mOomMinFree values. I've tried with all sorts of values, but when I get more multitasking, I also get more lag.
Do any of you have this issue (maybe my phone is faulty!?), or has found some values which offer a reasonable scenario for multitasking and lag?
Thank you.
This were the ones I was using:
Code:
ro.sys.fw.mOomMinFree1=20000
ro.sys.fw.mOomMinFree2=25000
ro.sys.fw.mOomMinFree3=27500
ro.sys.fw.mOomMinFree4=32500
ro.sys.fw.mOomMinFree5=62500
ro.sys.fw.mOomMinFree6=75000
Until I noticed the phone was quite laggy, and I doubled them. After a while it also got slow.
I'm happy with these values on fulmics 5:
61440
76800
87796
99512
138304
172880
Coolgoly said:
I'm happy with these values on fulmics 5:
61440
76800
87796
99512
138304
172880
Click to expand...
Click to collapse
Work absolutely fine with these values. Recommended
Sent from my LG-D855 using XDA-Developers mobile app
Hi, thanks for your responses.
I tried your values, but the system still killed the apps too aggressively for my taste.
I asked this same question in reddit, and I was suggested this:
Download the "kernel adiutor" app, open the low memory killer setting from the side menu and use this settings : foreground apps 12 mb, visible apps 15mb, secondary 15mb, hidden 24mb, content 30mb, empty apps 40mb. Dont forget to turn on "apply on boot". This setting isnt saved to the build.prop, I should've know that, sorry.
Click to expand...
Click to collapse
Although I can notice a little lag, this is (by far) more suited to my needs. I repost this here in case it is useful to someone else.
My only concern is whether I could avoid using kernel adiutor and hardcode these values in build.prop.
Anyway, thank you for your comments!