Related
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??
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 all,
On my Epic 4G I used to do a lot of tweaking to get good performance and one of those tweaks was to change the SD cache size from the default 128Kb to 1024Kb. My question is whether that's still a relevant or useful on the GS3?
I'm running stock, rooted, with no other tweaks (other than disabling apps and some developer setting changes). I was thinking of flipping to the higher cache size in ROM Toolbox but I wasn't sure it was something that still matters on a GS3... I don't know how the OS treats the various partitions (vis a vis, would this boost performance on extSdCard, or both internal and external, or neither).
Not that my GS3 is hurting for performance by any stretch of course, it's a beast already But hey, every little bit helps, and I especially like the types of tweaks you can do without dropping a new kernel and/or ROM... I used to go through custom ROMs like a fat guy through an all-you-can-eat buffet but these days I prefer staying as close to stock as possible, and the GS3 is the first device I've had where that's actually viable being so damned fast and smooth out-of-the-box
Thanks,
Frank
FYI, a quick test on this SEEMS to indicate it's a bad idea... I ran AndroBench with the default 128Kb and got the expected beastly numbers... I then changed to 1024Kb and ran it again... or more precisely I TRIED to run it again: AndroBench wouldn't even start the test suite, even after a couple or forced closes and retries. It may just be something specific to AndroBench, or it may point to the GS3 not liking that cache value, but I wasn't able to even confirm if there was a performance change either way.
So, unless someone knows differently, I'm leaving the cache setting at its default value, just to be safe.
I run at 2048 all the time with no issue.
So, it turns out the /preload partition is 500 megs of almost unused space, just to show us a video of Asphalt. So, how about turning it into swap space to almost double the effective amount of memory you have? To use this mod, you must be rooted, and have busybox installed. I recommend the stericson busybox installer https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
I would like feedback on whether or not it actually speeds up the device, especially when running graphics-intensive games, and also effects on battery life.
How to install:
1.Be rooted.
2. Get busybox. If you don't already have it, you can get it here https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
3. You must have init.d support. This is built into my NardROM but you can also flash the file attached to this post.
4. Flash the script installer, attached below. NOTE: This will wipe your /preload partition. You can make a nandroid before you perform this step but CWMR doesn't back up /preload. Back up anyway
5. If it's successful, you will see something like the following screenshot when you open a terminal window and execute "free". Notice the swap being used. If you don't have swap enabled it will read 0 available.
To disable the mod:
1. Delete the script from /system/etc/init.d
2. Reflash your Asphalt video from a backup
To disable init.d:
1. Delete /system/etc/install-recovery.sh, /system/etc/init.d (entire folder), /system/bin/sysinit, and /system/xbin/run-parts
Disclaimers:
Using nand memory as a swap can significantly reduce its life. Your phone's internal memory will wear out in years rather than decades
A lot of people argue using Android swap works against the built in memory management of the Dalvik machine
http://forum.xda-developers.com/showthread.php?t=1504774
This is awesome, glad to see people spending time on this device
Tappin' Typin'
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
ludacris1 said:
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
Click to expand...
Click to collapse
I think it's device-specific info for face unlock to compensate for various things like the angle you're holding the phone at and the distance away from your face. And if you'll look a little more closely, you'll find /vendor is symlinked from /system/vendor, it's not actually a separate partition. You should probably put those files back if you want face unlock to work.
Technically I just downloaded some ram
Sent from my SGH-I927 using xda app-developers app On Ics
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Same thing I was thinking. I have more than enough RAM but if by some miracle we get something past JB that uses a lot of RAM I'll do this. Nice work on it though!
sent from my captivate glide running ICS (NardROM 0.4 Rooted)
roothorick said:
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Click to expand...
Click to collapse
Waiting for the comparison,then
mewatashiakumoi said:
Waiting for the comparison,then
Click to expand...
Click to collapse
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
pm2gonzales said:
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
Click to expand...
Click to collapse
1) this is not a hack, this is a simple tweak
2) swap file is ALWAYS has a performance decrease effect, no matter what (desktop PC, android phone). The only reason of use is when the device has no enough RAM, and the background processes shall be kept elsewhere
3) android has it's own RAM managing system and methods, simply stick to that as only that will gives you the best performance and user experience
4) "slowdown" occurs when the device runs out of free RAM and starts closing background applications to give everything to the foreground app. When you close the heavy resource use foreground app witch caused android to close every possible background apps, the phone reloads them (launcher, live wallpaper, app drawer, widgets, user apps, etc...) and this is what causes a temporary slowdown, and this is unavoidable, no matter if you use swap or not.
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