Related
Can anyone explain the amount of RAM that this phone is suppose to have?
The specs for the phone lists 768 MB. However, the total memory that comes up is 617940 kB.
Thanks.
Bull Shot said:
Can anyone explain the amount of RAM that this phone is suppose to have?
The specs for the phone lists 768 MB. However, the total memory that comes up is 617940 kB.
Thanks.
Click to expand...
Click to collapse
where are you finding this number? i am at 758 MB. since i have a bunch of apps installed, that would seem about right.
How are you guys getting so much free ram? When I check on Task Killer, whenever I kill all the apps I'm not using it usually shows 358 mb ... and programs I'm not using automatically keep running (i.e Maps).
hmm maybe im not checking the right place? i'm getting my 758 mb number from settings--SD and phone storage. the internal phone storage tells me 758mb.
on an unrelated note though, you shouldn't use task killers. they are considered by most to be more of a drain on your battery life as android is already setup to manage closing unused apps on its own.
Many people use the term "memory" to mean system memory as well as storage. I try to avoid calling system storage as "memory" and tend to use "storage" instead, or refer to the type of storage.
Total ram is around 768mb. Part of it is reserved (not sure why, possibly for filesystem caching) so around 603mb is available. For this platform that is a healthy chunk of RAM to work with. Even with my hefty usage I have ~126mb free.
Internal storage is something like 2gb, with it partially consumed by the Android install as well as NAND configuration adjustments for reliability which cause some of the storage space to be consumed through hardware (there's an excellent explanation of this somewhere, don't have a link handy), resulting in about 1.1gb being available. I have 103 apps installed, 523.5mb of the internal storage used, with 638.8mb available.
There was an excellent tool posted on xda (http://forum.xda-developers.com/showthread.php?t=1066060) called Android Optimizer that gives a lot of good information about memory, storage, cpu usage, etc. I'd recommend checking it out. It's not available on the market and it is a little buggy so use it with a bit of caution if you choose to use any of the optimization functions.
cool. thanks for the explanation nimdae!
There have been so, so, so many posts on this topic that I will not rehash them all here. Instead, I will ask a simple question: For what do you use all that free RAM?
Ask yourself that question, and be serious about it. I think you will find yourself uninstalling your task managers and memory optimizers before long.
Edit: to avoid unnecessary discussion, Watchdog is in fact neither of those, and I would highly recommend it as the only memory app you will ever need.
Edit 2: the total RAM displayed is the RAM that is actually available to be used by anything the user may want to run. As a poster earlier said, the system reserves a certain amount of RAM for its own use to keep important processes moving along. The reserved RAM is not available, and so doesn't appear in total RAM. Unless you want to uninstall the OS. Then you could have access to all 768 MBs.
I would like to reiterate why you should not use automatic task killers.
As of, I believe, Android 2.0, the garbage collection and memory management was significantly improved. However, this was not a new system in Android, it always existed.
How it works:
If you haven't noticed with Android, when you leave an app, it doesn't close it unless the app specifically does something to end the process. This is by design. Android allows the app to remain in memory. Frequently used apps will load faster with this design. A "task" that is not killed and is in the background ONLY consumes memory, it does not "run" (in Linux terms, the process is actually in a "stopped" state so the task can't do anything anyway). Only a "service" can run in the background. Most apps that have long running services have lightweight services.
If an application loads that requires more memory than is available, Android will examine backgrounded tasks for candidates to be killed to free up memory. This makes it so as many tasks as possible can remain in memory for better performance. In understanding this, you should know that if you have a large amount of memory, and memory usage is high, this is a GOOD THING. With the amount of memory in the I2, there is a lot of breathing space for this.
There is one other case where a backgrounded task will be killed: if it has been in the background for a certain period of time without being brought forward. Killing a task to free up memory to load another task can actually be a little cpu expensive (but not THAT much) so this can make it slightly easier.
Please note that backgrounded tasks WILL NOT contribute to battery drain. Only tasks at the front and services will. Killing your backgrounded calculator will do nothing for you other than free that small amount of memory it uses. Used memory does not contribute to extra battery drain as DRAM refreshes happen on ALL cells anyway.
Background services can also be made candidates for being killed. If an app needs more memory than can be made available by killing backgrounded tasks, then services become targets to be killed as well.
Automatic task killers cause a couple of problems. A less major problem is you lose that one benefit you get by keeping tasks in the background: performance. I don't just mean how fast it loads. If it can bring a backgrounded task to the front from memory rather than load from storage, you remove extra processing to load the app, including storage access, that contribute to higher battery drain. The other problem is a poorly configured task killer can break things like notifications.
Managing your services is always a good idea. Having a lot of services running means background processes that are capable of contributing to battery drain. Additionally, there are apps with misbehaving services (services that consume resources or use features they shouldn't). While I'm against automatic task killers, using something to monitor and manage services is a good idea. Just always keep in mind the implications for killing a service: it may affect a feature to an app that you would rather not impact.
Excellent explanation nimdae! Task killers are the devil.
On another note, my posts are getting too long...
nimdae said:
On another note, my posts are getting too long...
Click to expand...
Click to collapse
Everything is longer in Texas.
xgunther said:
Everything is longer in Texas.
Click to expand...
Click to collapse
That's what s...no, that's too easy.
Move along, nothing to see.
Before I read this I was like a task Nazi. I killed my tasks often, but now I think I will just let them be. Nice write up BTW. Very informative.
Sent from my ADR6350 using XDA App
TB13 said:
Before I read this I was like a task Nazi. I killed my tasks often, but now I think I will just let them be. Nice write up BTW. Very informative.
Sent from my ADR6350 using XDA App
Click to expand...
Click to collapse
Remember: I'm not saying don't manage things. Poorly behaving services are the #1 cause of high battery drain (at least on non-LTE devices), and this will be even more problematic when you overclock.
xgunther said:
Excellent explanation nimdae! Task killers are the devil.
Click to expand...
Click to collapse
I tried not using them and I get better battery life with them...I use it maybe 3 times a day after heavy multi tasking. It's to each their own..but I see results for it..like 5 extra hours.
Sent from my ADR6350 using XDA Premium App
knipp21 said:
I tried not using them and I get better battery life with them...I use it maybe 3 times a day after heavy multi tasking. It's to each their own..but I see results for it..like 5 extra hours.
Sent from my ADR6350 using XDA Premium App
Click to expand...
Click to collapse
If you get that much extra, you have a misbehaving app. Better to get the app developer to fix it or find an alternative.
nimdae said:
If you get that much extra, you have a misbehaving app. Better to get the app developer to fix it or find an alternative.
Click to expand...
Click to collapse
True, I don't need to use it often though lol
Sent from my ADR6350 using XDA Premium App
I'm in Texas as well.
sent from a phone without root.
I use a task killer only to manually kill an app that freezes or something. Its easier than going to manage applications. I have the autokill disabled.
Sent from my ADR6350 using XDA Premium App
AngelsPunishment said:
I use a task killer only to manually kill an app that freezes or something. Its easier than going to manage applications. I have the autokill disabled.
Sent from my ADR6350 using XDA Premium App
Click to expand...
Click to collapse
CyanogenMod (maybe other ROMs) have a feature to kill a frozen app by holding the back button (long press, whatever). However, this can also be an annoyance on systems where for unknown reasons it registers a long press on a tap (my eris did this a lot).
Maybe someone already asked but I couldn't find it. I've had my rooted Inc for about 4 months and still trying Roms out. However whatever rom I use, except cm7, I get some lag. Some slow load times and such when I unlock or open a new app. I'm just curious if its an Inc problem, a sense problem, or maybe my hardware was ddamaged. I bought the phone refurbished from verizon
Sent from my ADR6300 using XDA App
infidelmatt said:
Maybe someone already asked but I couldn't find it. I've had my rooted Inc for about 4 months and still trying Roms out. However whatever rom I use, except cm7, I get some lag. Some slow load times and such when I unlock or open a new app. I'm just curious if its an Inc problem, a sense problem, or maybe my hardware was ddamaged. I bought the phone refurbished from verizon
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
If it was a hardware issue, even CM7 would show it. Sense ROMs have a lot going on, especially when you go to unlock the screen. Some kernels will switch governors to Performance as soon as the screen is turned on and until it's unlocked. Scripts can be written to accomplish this in most kernels.
Certain widgets, such as the SetCPU widget, will bring things to a grinding halt with the graphics. I can't tell you why, but I've used a few apps where the widget for it was whacky like that.
Newer Sense versions are also going to entail some lag as well. Overclocking will help a little, but the GPU in that device isn't real powerful and is easily overwhelmed by a Sense 3.0 environment. The limited memory is an issue as well.
If you can, create a swap file. That will free up some memory.
Do NOT use task killers. They slow everything down by killing apps that need to be restarted, thus taking up NAND bandwidth, eating power, and freeing up RAM that's there to allow for recently used apps to run faster.
Wipe your Dalvik cache with each new ROM/Kernel. A properly built Dalvik cache is there to minimize app launch lag. Basically, it's a cache of application byte code that's been pre-compiled so that it can be executed while the JIT compiler determines the most efficient compiling of the remaining application code.
On the dInc, my SCcard seemed to access files quicker than if stored on the internal eMMC. Moving your Dalvik cache to the SDcard could allow it to be accessed faster since it's not sharing bandwidth with the rest of the system trying to access OS and app data from eMMC. I don't know if there's a way to test that or not, but it might be worth a try.
Check number and frequency of items synched; quick hit on responsiveness. Task killer or antivirus installed? Uninstall to see whether they are the culprit.
Sent from my ADR6300 using XDA Premium App
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
WHAT DOES ART AND DALVIK EXPERSSIONS MEAN IN THE NEW 4.4 ROMS?
aliesz said:
WHAT DOES ART AND DALVIK EXPERSSIONS MEAN IN THE NEW 4.4 ROMS?
Click to expand...
Click to collapse
Please do some reading and maybe googling: http://lmgtfy.com/?q=art+and+dalvik+explained
Sent from my Galaxy Nexus using XDA Premium HD app
ART is a new app runtime. It's more powerful than dalvik but it can't run all apps currently.
So after reading up and please correct me if I'm wrong, seems like ART is simply replacing dalvik "cache" with completely unzipping the APK files to the storage memory during install so no need for cache or virtual machines, but each app will take longer to install and may require additional storage.
Henceforth Android apps should load/run as fast/er as iOS/WP apps, regardless of phone/tablet CPU/RAM specs.
I think it's just a method to end(slowdown) piracy likely by implementing encrypted serial ID's to every APK install.
isajoo said:
So after reading up and please correct me if I'm wrong, seems like ART is simply replacing dalvik "cache" with completely unzipping the APK files to the storage memory during install so no need for cache or virtual machines, but each app will take longer to install and may require additional storage.
Henceforth Android apps should load/run as fast/er as iOS/WP apps, regardless of phone/tablet CPU/RAM specs.
I think it's just a method to end(slowdown) piracy likely by implementing encrypted serial ID's to every APK install.
Click to expand...
Click to collapse
ART doesn't "unzip" the "cache" from the APK files, but rather "compile" them into native code onto the device (which takes up more space but starts much more quickly).
Also, ART is still in an alpha/experimental stage, so it remains to be seen just how well it will improve app start-up time (although some benefits are already noticeable).
AFAIK, ART stands for Android Run Time (yeah, lame, i know).
ART simply compiles the apk during installation where dalvik compiles it as you load the app into memory. So ART will take up more space on your device, less load on cpu, thus being more battery friendly....less load on memory too i believe, although i am not too sure on that one....
dalvik on the other hand, might need to recompile the app everytime you load it back into memory, causing more load to cpu and thus, more battery drain.
speaking of which, is there any rom using ART atm? I am still waiting for the official CM11, kinda waiting for them to fix all the glitches and bugs. But is there any rom enabled ART already?
hhwong said:
AFAIK, ART stands for Android Run Time (yeah, lame, i know).
ART simply compiles the apk during installation where dalvik compiles it as you load the app into memory. So ART will take up more space on your device, less load on cpu, thus being more battery friendly....less load on memory too i believe, although i am not too sure on that one....
dalvik on the other hand, might need to recompile the app everytime you load it back into memory, causing more load to cpu and thus, more battery drain.
speaking of which, is there any rom using ART atm? I am still waiting for the official CM11, kinda waiting for them to fix all the glitches and bugs. But is there any rom enabled ART already?
Click to expand...
Click to collapse
I am currently running swordrune's Unofficial CM11 build on ART, I have been for almost 2 weeks with no reboots, lockups or app force closes. The rom is rock solid. The only issues left are the graphical glitch on the screenshot preview (which does not affect the actual screenshot) and the black screen on panoramic camera mode. Other than that this rom is 100% perfect, every app I have works fine with ART.
Thanks a lot my dear friends
Sent from my Galaxy Nexus using Tapatalk