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
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?
just performed some tests with different reserved mem sizes (stock kernel ZSJP8) for your ref
default settings:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=10240
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=14336
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=36864
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=5012
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240
1/. minimum (almost) reserved mem with movie playback possible (no lag in youtube), 356mb memory, no special lags observed, opened 4 tabs in browser with lots of imgs and swfs
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=4096
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=6144
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=29696**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=3072
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=2048
** min value in order to play movies = 29mb, 28mb wont play
## can be set to a lower value without movie playback, setting these with too low values caused problems, below 20mb should be ok
2/. nearly double all default values, 219mb available, didnt feel faster
EDIT 201010271843HKT: tweaking memory test2
available memory - 257.68mb
EDIT 201010280000HKT:
as to min mem usage, u'll need to (in brief):
1/. remove unneccessary apps
2/. remove startup/network chg broadcast listeners from the app - a lot of apps/services are launched at startup up or network state chg, remove them so they wont start automatically, eg gtalk, sync/feed, vold service, installd, etc
3/. kill unneccessary services & processes - i didnt use any killer since i rooted my phone, i use script to kill them since killers consume more mem
4/. i have read the source and found that only -Xmx (max mem) is included but no -Xms (initial mem), perhaps we can do something here (not done yet)
reference for 2.1 http://forum.xda-developers.com/showpost.php?p=8507031&postcount=38
It 's very useful info! thanks your test!
Can I have a guide to make these changes to my existing kernel?
Nice, able to see 356MB instead of 304!
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=6144
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=4096
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=5012
can make one kernel for this setting? i want to test,but i don't know how to make a zimage.
These results exclude the 'blackholed' memory, right? Which means if we can find where it is used (if it is used at all) we can get even more?
Great work there. Could gain us a couple more MB of usable RAM.
The "48MB hole" is most likely used by the GSM Radio and we won't have access to it.
xos84292 said:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=6144
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1500
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=8192
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=30720**##
CONFIG_VIDEO_SAMSUNG_MEMSIZE_JPEG=4096
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=5012
can make one kernel for this setting? i want to test,but i don't know how to make a zimage.
Click to expand...
Click to collapse
i'm sorry, my kernel will restart once the usb cable is unplugged, still looking for a solution....
jam3sjam3s said:
These results exclude the 'blackholed' memory, right? Which means if we can find where it is used (if it is used at all) we can get even more?
Click to expand...
Click to collapse
what blackhole r u talking about?
This is awesome! I can't wait to see a kernel with the resolved usb issue and more ram.
Yay! Finally we have experts working on the RAM issues!
BTW, is there no way to allocate memory dynamically for all these things as and when it is needed instead of reserving a set amount? Especially for the video playback stuff, it's a lot of wasted memory when you're not playing a movie / doing something graphic intensive.
Can anyone explain how to do a safe changes of this paremeters.....?
Thanks
Try 720p video capturing, encoding is hardware accelerated as well. (but might not be affected by those settings, it just needs checking)
Yes, dynamic allocation would be awesome
Those settings are accessible in source code = before compilation, so no way to change them post-startup/post-compilation ATM.
How come u got only around 100MB memory used?
I got over 140 just after startup..
This is still not 512MB as samsung promissed us! I hate this phone! I'll buy a Desire Ultra HD as soon as it's annoucned!
(just to be the first troll in this topic )
nice work though!
sztupy said:
This is still not 512MB as samsung promissed us! I hate this phone! I'll buy a Desire Ultra HD as soon as it's annoucned!
(just to be the first troll in this topic )
nice work though!
Click to expand...
Click to collapse
I don't think that the argument ever was that Samsung promised 512MB of usable RAM. It was that the amount of RAM usable out of 512MB for applications was not comparable to other phones with 512MB.
I don't want this to turn into an argument. I'm just glad that the problem is coming to fruition.
andars05 said:
I don't think that the argument ever was that Samsung promised 512MB of usable RAM. It was that the amount of RAM usable out of 512MB for applications was not comparable to other phones with 512MB.
I don't want this to turn into an argument. I'm just glad that the problem is coming to fruition.
Click to expand...
Click to collapse
You clearly either have no sense of humor or cant read
I know it was sarcastic. He was making fun of the people who wanted more RAM. I was just stating that no one (with exception of a few maybe) expected 512MB of RAM to be fully usuable. I think he misunderstood the original issue
I believe the issue was largely ignored because of this misunderstanding. It didn't help that people who expressed dissatisfaction were told to "stfu." A good portion of people were unhappy with the amount of available RAM. It wasn't that they expected to have full access to all 512MB.
I'm happy to see progress on this issue.
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
SupaDuckie said:
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Any kind souls?
SupaDuckie said:
How are we able to change theSe values???
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
mengsuan said:
Any kind souls?
Click to expand...
Click to collapse
How about reading? Its just freakin 2 pages, not 50...
I know, many people here want to have Android 4.x.x on their phones, but unfortunately, because of low-end processor as well as less RAM, these CM10/CM10.1 ROMs are laggy and slow. I am also one of them, but, after using these type of roms since 4 months, I have now got a perfect idea of using them. So, I am sharing the way I use these roms. Many people told that this also helps for CM7 users. So, now I have declared this thread as UNIVERSAL PERFORMANCE THREAD. This method can be used on - Stock | CM7/9/10/10.1.
NOTE : This thread is mainly from galaxy mini forums. But, I have posted it here also, so that Gio users also get its benefits.
NOTE : This method is same for PAC ROMS.. because they are based on CM. So, you can use this on PAC ROMs also.
♦ FINDING STABLE VERSION :
First of all, you will need to find a good stable version of any CM7\CM9\CM10\CM10.1 ROM. Find stable version by asking in general discussion thread of those particular ROM and then download that version. But, do not flash now.. Follow next step.
Note : For CM7 users - Official CM7 is best, but if you want you can try it on custom roms also. If you are using CM7 custom or stock based custom rom, then for scripts n tweaks to work, you must delete all the scripts from init.d so that scripts will not get overridden.
♦ SLIMMING THE ROM :
Slimming means making rom size less by removing unwanted and unnecessary applications from system/app. It reduces system memory use. Here is a chart of cm10.1 apps which are safe to remove - LINK
With reference to that chart you should remove following apps with adding alternatives to them.
Note: Left side apps are to be removed and right side apps are alternatives.
● LatinIME.apk - WP7 Keyboard App
● Browser.apk - Holo Web Browser
● CMFileManager.apk - Root Explorer File Manager
● Trebuchet.apk - Holo Launcher
NOTE: On CM7, default ADW is good, but you can also use Holo Launcher.
Other apps that can be removed without alternatives-
● CalendarProvider.apk - One of the big RAM consuming apps. This app start anytime, you do anything, so it will be a big save of memory removing this app. But, you will get problems with calendar sync..
● GoogleCalendarSyncAdapter.apk - Reomove this only if you do not sync calendar.
● Email.apk - If not in use.
● Gmail.apk - If not in use.
● Talk.apk - If not in use.
● GoogleBackupTransport.apk - It is used in google backups, remove on your own risk. (Not a risk, i always remove it.)
● ChromeBookmarkSyncAdapter - No use.
● HTMLViewer.apk - Never needed.
● UserDictionaryProvider.apk - It is useless without LatinIME.apk.
● VisualizationWallpapers.apk - Wallpapers app. Remove it always.
● CMWallpapers - Remove it always.
● VoiceDialer.apk - Do you really use it?
● LiveWallpapers.apk - Dont you care for your battery?
● QuickSearchBox.apk - If you dont use.
● PicoTTS.apk - Text to speech function.
NOTE: Alternative apps should always be installed in system/app only. For that, I recommend you to remove these apps drectly from rom's zip before flashing.
♦ USE OF SCRIPTS N TWEAKS :
Many people use hard scripts n many tweaks to get good performance. But, it is totally wrong.
Highly recommended to use Activo Speeder. It is the best script for performance. Dont use anyother thing with it- such as ram manager, seeder or anyother script.
(Note: If the above script doesnt work on your device then please find another good script and flash it.)
IT IS RECOMMENDED TO USE SUPERCHARGER ON ICS\JB :
After testing a lot, I found that SuperCharger is the best script which can be used with any ROM to get more performance and for perfect RAM Management. Here are some steps on how to use SuperCharger -
● Here is the original thread for SuperCharger script.
● Script can be downloaded from this download page.
● Download latest script as well as starter package if needed (Read Original Thread).
● Now, for 4.x.x ROMs, you do not need to do anything with services.jar. But, for below 4.x.x, services.jar needs to be patched to get SuperCharger Memory Management working.
● Now, copy script to SDcard and run it with Script Manager as root. For more detailed guide plz prefer the original supercharger thread.
● Now, you are running the script. You will find many options and info on screen. Read it all and choose what you want.
NEW DISCOVERY : SUPERCHARGER + CROSSBREEDER = ULTIMATE PERFORMANCE WITH MAX ENTROPY ! - by Dark Passenger
● LINK FOR THE POST.
Here are some tweaks-
In Build.prop -
●
Code:
ro.ril.disable.power.collapse=0
and change the value from 0 to 1. (Add the line with proper value if does not exist)
This one is for battery saving.
●
Code:
dalvik.vm.heapgrowthlimit=48m
If it already exists then just match the values.
This is a VM Heap management for RAM.
●
Code:
ro.ext4fs = 1
Improves EXT4 performance.
● IMP :
Add following lines below "# Other" in build.prop
Code:
ro.com.google.locationfeatures=0
ro.com.google.networklocation=0
(If exists, just change the values as above).
(Note: This one will remove location feature increasing performance freeing up more RAM. This frees up to 30mb of RAM)
And now remove NetworkLocation.apk from system/app as well as com.android.location.provider.jar from /system/framework.
For further build.prop tweaking, you can use this great guide -> Click Here. Thanks to Dark Passenger for some build.prop tweaks.
This much tweaking and scripting is enough. DONT USE TOO MUCH TWEAKS N SCRIPTS.
♦ BASIC APPS TO USE :
Your rom's performance also depends on the apps which you use. Always look for apps' memory usage and if the app consumes more ram then try to find an alternative app for it. Here are some basic apps which you should use (i always use them).
● Use Root Explorer as file manager, Holo Launcher as Launcher.
● Use Cache Cleaner App. It is must. Clean cache once a day.
● Use Root Cleaner App. A must have app. Do "Quick Cleaning" twice a day. It will regulate your performance.
You can also freeze the apps you are not using at that time, such as DSPManager (Unfreeze it only at the time of listening songs)
Freezing Google Apps will be a great way to reduce RAM consumption.
● Use this amazing app - Autostarts. This app controls the apps that start automatically in your phone. If you want settings which I use then PM me. I will tell you, how to use this app.
CLICK HERE FOR AUTOSTART APP SETTINGS
● ABOUT TASK KILLERS :
Using task killer is good but, it is also bad. Task killing is actually meaningless. Some apps never really get killed. They start again n again. So, use Autostarts instead task killers. But, here is a nice app for killing processes and freeing RAM. This is the original app. I have themed it to look good. Download it here.
Use it as a task killer, press menu button and include system processes and then start killing processes which are useless.
● Try to use apps as system apps.
● If you are using UC Browser then in its settings, check "Clear Data on Exit". If did, you will see UC will take less than 10mb but, if you wont do this, UC will take more than 15mb.
♦ IMPORTANT TIPS AND SETTINGS :
● Always flash rom with a clean wipe and proper flashing method.
● Do not flash gapps again if they are included in the rom.
● Do not flash internal memory scripts as they reduce performance.
● Use Adrenaline Boost. Boost once or twice a day. Boosting much will increase battery consumption.
● Use Root Cleaner app and freeze the apps which you are not using at that time. Freeze Google Play Store, Google Services Framework and other google apps which are always on. Unfreeze them when you want.
● The apps used for Backup purposes should not be installed always. Keep them in your sdcard and install them when you want and uninstall when done with them.
● Basic apps should always be in system/app.
● In Developer Options -
Set all animations scale to .5x
Set Background Process Limit to "Atmost 4 processes", if issues occur then set it back to "Standard Limit".
Enable "Kill App Back Button". Always use this feature to come out of the apps which do not really exit on pressing just back button.
● Do not expect much from our phone as it is not a high-end phone. Dont expect good battery life but, still to gain good battery life. Keep RAM free by using the ProcessKiller app as told above. I always get 170 mb RAM free.
● Do not charge battery until it gets discharged upto 10% or less. While charging do not remove it till it reaches 100% and 20 mins above that.
● Calibrate battery when needed.
● Avoid use of apps which are always running either in background or foreground.
● Press thanks. .
Thanks! I'm definetely going to try this out, even though I'm not running JB but ICS.
Deleting unneeded apps works on every Android version I think, and ActivoSpeeder works on ICS too, so I'm happy!
StiQuezNL said:
Thanks! I'm definetely going to try this out, even though I'm not running JB but ICS. Deleting unneeded apps works on every Android version I think, and ActivoSpeeder works on ICS too, so I'm happy!
Click to expand...
Click to collapse
As I hv mentioned in the title.. this method is for all ROMs.. It is not needed that you should be running JB only.. it is for all...
Noobwithdumbquestions said:
this made everything a lot more laggy and gmail stopped syncing... Also takes about 3 times as long to boot.
No offence, but this is pretty terrible. And after doing some actual research a lot of the "tweaks" you talk about here are never proven effective and frowned upon by actual experts. Even in the article you linked the writer says that something like dalvik heapsize is not something you should or have to change.
I would advice anyone to NOT waste any time on this.
ps: the last part (under tips and settings) is actually some good advice, although the background process limit is not saved in CM10 (and the max.mem tweak doesnt work), so you'll need to do that everytime at startup
Click to expand...
Click to collapse
please dude if you don't know how to tweak you can go i don't use this guide but it's a good one maybe you installed all those thing over a already tweaked rom, this guide if for clean stock, cm7/9/10/10.1
Nice guide...but I think you are wrong about the services.jar. You have to patch it when you use ICS or Jelly Bean, not on GB. And there is no Official CM7 on Gio.
Verstuurd van mijn GT-S5660
Verstuurd van mijn GT-S5660
tcris45 said:
please dude if you don't know how to tweak you can go i don't use this guide but it's a good one maybe you installed all those thing over a already tweaked rom, this guide if for clean stock, cm7/9/10/10.1
Click to expand...
Click to collapse
I applied it on a clean cm10.1 twice, had the same results, twice. I am not trying to talk down on someone elses work, but the fact is that some of the "tweaks" he talks about are never proven and often based on urban myths and the perception of people who applied them and saw improvement (placebo effect). fwiw, OP himself links to an article that busts some of the myths about tweaks, he tells people to apply...
So, maybe my device didnt start to lag more, in fact, it might have been more stable... however, setting the fs.file-max too big (as is one of the many things that activo script does) will make it less responsive, like there is a 100ms sleep between every action... I also experienced that with manual sysctl.
And some other tweaks that do work are still not great for everyone because they got other side effects that are not mentioned anywhere in this article. I got no idea why sync started giving errors and gmail stopped updating (twice) after these tweaks, but they did....
I am completely new to android, and should've done more research before blindly following some article that states to have some magical cure. But I am not new to linux and it seems this community suffers from the same kind of idiosyncrasies at the bottom end, where people constantly try to fix **** that isnt actually broken.
I'm talking about tweaks here obv, removing gapps. bloatware and lowering requirements for the OS is obv fine...
When someone's Gio lags, it's probably because they want to do stuff with it it's not made for, it's a slow device with minimal specs that does the pure core tasks as pda, phone, messenger and email, and as long as you do those it'll be fine. If you want more, buy a better phone. If it's that important to you and you dont have money, learn to appreciate what is actually important in life.
Nuff said.
Noobwithdumbquestions said:
I applied it on a clean cm10.1 twice, had the same results, twice. I am not trying to talk down on someone elses work, but the fact is that some of the "tweaks" he talks about are never proven and often based on urban myths and the perception of people who applied them and saw improvement (placebo effect). fwiw, OP himself links to an article that busts some of the myths about tweaks, he tells people to apply...
So, maybe my device didnt start to lag more, in fact, it might have been more stable... however, setting the fs.file-max too big (as is one of the many things that activo script does) will make it less responsive, like there is a 100ms sleep between every action... I also experienced that with manual sysctl.
And some other tweaks that do work are still not great for everyone because they got other side effects that are not mentioned anywhere in this article. I got no idea why sync started giving errors and gmail stopped updating (twice) after these tweaks, but they did....
I am completely new to android, and should've done more research before blindly following some article that states to have some magical cure. But I am not new to linux and it seems this community suffers from the same kind of idiosyncrasies at the bottom end, where people constantly try to fix **** that isnt actually broken.
I'm talking about tweaks here obv, removing gapps. bloatware and lowering requirements for the OS is obv fine...
When someone's Gio lags, it's probably because they want to do stuff with it it's not made for, it's a slow device with minimal specs that does the pure core tasks as pda, phone, messenger and email, and as long as you do those it'll be fine. If you want more, buy a better phone. If it's that important to you and you dont have money, learn to appreciate what is actually important in life.
Nuff said.
Click to expand...
Click to collapse
Look in signature, this thread is also there for Fit as well as Mini and is getting good response all over.. but you are the first one to complain on this. My advice to you- DO NOT USE THIS DO NOT POST HERE!
Some of your sayings are correct but, still this is the best way to increase performance. You might have did something wrong because this has been researched by me and some other people that this guide is perfect for low activity devices like ace, fit, mini, but if you dont want to use then dont use. I have NO PROBLEM.(I really dont get money or anything for this). lol..
FlemishDroid said:
Nice guide...but I think you are wrong about the services.jar. You have to patch it when you use ICS or Jelly Bean, not on GB. And there is no Official CM7 on Gio.
Verstuurd van mijn GT-S5660
Verstuurd van mijn GT-S5660
Click to expand...
Click to collapse
Yeah services.jar needs to be patched on ics and jellybean only. I didnt knew that official cm7 is not there for gio.. I dont own this device. sorry.
Noobwithdumbquestions said:
I applied it on a clean cm10.1 twice, had the same results, twice. I am not trying to talk down on someone elses work, but the fact is that some of the "tweaks" he talks about are never proven and often based on urban myths and the perception of people who applied them and saw improvement (placebo effect). fwiw, OP himself links to an article that busts some of the myths about tweaks, he tells people to apply...
So, maybe my device didnt start to lag more, in fact, it might have been more stable... however, setting the fs.file-max too big (as is one of the many things that activo script does) will make it less responsive, like there is a 100ms sleep between every action... I also experienced that with manual sysctl.
And some other tweaks that do work are still not great for everyone because they got other side effects that are not mentioned anywhere in this article. I got no idea why sync started giving errors and gmail stopped updating (twice) after these tweaks, but they did....
I am completely new to android, and should've done more research before blindly following some article that states to have some magical cure. But I am not new to linux and it seems this community suffers from the same kind of idiosyncrasies at the bottom end, where people constantly try to fix **** that isnt actually broken.
I'm talking about tweaks here obv, removing gapps. bloatware and lowering requirements for the OS is obv fine...
When someone's Gio lags, it's probably because they want to do stuff with it it's not made for, it's a slow device with minimal specs that does the pure core tasks as pda, phone, messenger and email, and as long as you do those it'll be fine. If you want more, buy a better phone. If it's that important to you and you dont have money, learn to appreciate what is actually important in life.
Nuff said.
Click to expand...
Click to collapse
okay go step by step and tell me what is it that is actually bothering you about the tweaking.(talk only about supercharger method not activ speedo).
yes most of the tweaks are utter bull**** The tweaks in the op(build prop ones are actually proven read the article again).As for dalvik size its recommended to keep a size around 48 so that you processes don't need to split their dalvik heaps into two separate piles thus reducing ram consumption.
Dark Passenger said:
okay go step by step and tell me what is it that is actually bothering you about the tweaking.(talk only about supercharger method not activ speedo).
yes most of the tweaks are utter bull**** The tweaks in the op(build prop ones are actually proven read the article again).As for dalvik size its recommended to keep a size around 48 so that you processes don't need to split their dalvik heaps into two separate piles thus reducing ram consumption.
Click to expand...
Click to collapse
I didnt use the supercharger method... The OP says the activo speedo is recommended, and the supercharger method is proposed as an alternative... I already said what problem I had with it (the response thing, and believe me or not, to me this difference is obvious and makes sense, I was able to reproduce it with just changing some of the same sysctl settings myself) but I wouldnt be surprised if there were more as it seems to do a buttload of things.
As far as the heapsize goes, I am not basing my conclusions on anything other than the OP's own link, which says things like:
dalvik.vm.heapgrowthlimit and dalvik.vm.heapsize - BUSTED,
Click to expand...
Click to collapse
This is one property that has cropped up recently in various build.prop recommendations for ICS. Typical suggested values range from “48m” all the way up to “256m”, likely motivated by the common misconception that more is better. The real purpose of this property is much less obvious than one might initially guess. It is also another one you should probably avoid changing.
Click to expand...
Click to collapse
Should you change this setting? Probably not.
Click to expand...
Click to collapse
Maybe you are right, I dont know all the technical implications, and I got no way to check it other than to test it and I see no difference in ram consumption if I change this property.
The ro.power.dissable thing might shut off wifi when in deep sleep and jumps back to mobile (I think, it happened after applying all tweaks and it seems the most likely thing to do that), but whatever causes that, you should warn people about that sort of thing as it can cost them money..
I didnt use it for long and I'm not an expert, i'm just sharing my findings, people can make up their own mind about it and share their experiences as well..
OJ said:
Look in signature, this thread is also there for Fit as well as Mini and is getting good response all over.. but you are the first one to complain on this. My advice to you- DO NOT USE THIS DO NOT POST HERE!
Some of your sayings are correct but, still this is the best way to increase performance. You might have did something wrong because this has been researched by me and some other people that this guide is perfect for low activity devices like ace, fit, mini, but if you dont want to use then dont use. I have NO PROBLEM.(I really dont get money or anything for this). lol..
Click to expand...
Click to collapse
Sorry, I didnt mean to offend you in any way and appreciate your effort... But telling me to stop posting just because I'm critical seems pretty backwards. If you only want people to say thanks and be greatful all the time, maybe you should start sharing horse pictures on a hello kitty forum...
I'm just sharing my experience and my problems might be related to my rom and it could very well work great on other phones or other roms... But I used a clean cm10.1, the CM10.1 rom almost everyone with a Gio uses, so I'd think it's still important to bring up my findings...
Noobwithdumbquestions said:
I didnt use the supercharger method... The OP says the activo speedo is recommended, and the supercharger method is proposed as an alternative... I already said what problem I had with it (the response thing, and believe me or not, to me this difference is obvious and makes sense, I was able to reproduce it with just changing some of the same sysctl settings myself) but I wouldnt be surprised if there were more as it seems to do a buttload of things.
As far as the heapsize goes, I am not basing my conclusions on anything other than the OP's own link, which says things like:
Maybe you are right, I dont know all the technical implications, and I got no way to check it other than to test it and I see no difference in ram consumption if I change this property.
The ro.power.dissable thing might shut off wifi when in deep sleep and jumps back to mobile (I think, it happened after applying all tweaks and it seems the most likely thing to do that), but whatever causes that, you should warn people about that sort of thing as it can cost them money..
I didnt use it for long and I'm not an expert, i'm just sharing my findings, people can make up their own mind about it and share their experiences as well..
Click to expand...
Click to collapse
the ro.power.disable.ril actually causes the phones radio to go to sleep so if your mobile data is off there is no reason to switch on rather the wifi might switch off(devs already stated so) and again switch back on once you get out of deep sleep.
its a good thing that you are coming back to provide a feedback and is appreciated(at least should be).
the change for dalvik.vm larger than 48 only allows the heap to grow to that value then split into a new heap since we can't/shouldn't/don't use apps with such a large memory footprint the chances of a split occurring post 48mb(gb and below) and 64mb(ics and above) is highly unlikely hence the changing the value to a larger quantity will make no difference.
PS personally even i dont like activo mainly cause i dont know how it works rather i use supercharger and its a much better option in my opinion.
Sorry, I didnt mean to offend you in any way and appreciate your effort... But telling me to stop posting just because I'm critical seems pretty backwards. If you only want people to say thanks and be greatful all the time, maybe you should start sharing horse pictures on a hello kitty forum...
I'm just sharing my experience and my problems might be related to my rom and it could very well work great on other phones or other roms... But I used a clean cm10.1, the CM10.1 rom almost everyone with a Gio uses, so I'd think it's still important to bring up my findings...
Click to expand...
Click to collapse
No, I already told you that many of your ideas are correct but, your way of expressing was not good.
Ex- You said that "Dont waste time on using this guide".
Now, if you think that was correct then please do not post again. If you are providing information then you can but, if you are telling people not to use this then dont post.
In fit's thread, Dark Passenger also wanted to express his ideas and wanted to help me. And I was happy about that. Because the way he helped me was like he really wanted to help. But, you was not polite as him.
You can ask Dark Passenger, there is a lot of information in the thread provided by him and I used that. And he never complained like you.
@Dark Passenger, please explain him.
OJ said:
No, I already told you that many of your ideas are correct but, your way of expressing was not good.
Ex- You said that "Dont waste time on using this guide".
Now, if you think that was correct then please do not post again. If you are providing information then you can but, if you are telling people not to use this then dont post.
Click to expand...
Click to collapse
Yeah, I was frustrated and my first response was not really fair. I agree.
Noobwithdumbquestions said:
Yeah, I was frustrated and my first response was not really fair. I agree.
Click to expand...
Click to collapse
When you use ics or jelly bean you need supercharger script and a patched services.jar (it's easy to do) because any other script don't works 100 % on it.
Sent from my GT-5660 using xda premium
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.