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??
Hello,
Until yesterday i never OCed my desire, I had DJ Droid rom and it was always smooth and slick in terms of interface and apps jumpiness.
Yesterday I decided to try the 1384Mhz rom from OpenDesire. Done full wipe of course, installed the ROM, then after the installation my Desire was pretty hot (probably due to all sync apps work) even before i installed set cpu or did any OC.
Then I said, ok lets try OC, I installed Set CPU, And tried 1300Mhz level and also the maximum levels. and it froze up, i had to pull off the battary and reboot.
Then I tried 1272, Again froze up during browsing...
Then I tried 1Mhz and ran stress test for long, no errors no freez ups.
However, OpenDesire wasnt slick and smooth for me, I mean during sliding the apps menu, it was not smoooth i felt some slowdowns... same about the main interface windows slide right/left. especially with live wallpapers from some kind.
Is it normal? Could I damage something in my CPU/GPU due to this OC? Which causing this?
I tried even full wipe and again from zero placing the OD rom...still had same feeling of none smoothness.
thanks
Any ideas?
I had this problem. I usually leave my Desire overnight so it can sync, titanium backup, fix permissions etc.
After installation of OD, I find that just signing in, then rebooting, installing extras like statusbar then rebooting, then titanium restore, fix permissions, then a reboot usually sorts me out, leaving my desire on sync overnight (market is very slow after fresh install for me =/)
Very long process
OD supports ext3 for A2SD+. Some users have reported that they had problems with several A2SD roms because they haven't got a ext2/3 partition, or a ext4 which I don't think is supported on OD. This can slow a rom down severely, as the phone is looking for the sd-ext partition.
Final mention would be setCPU itself.
Saying this, I have had issues with the performance scaling or whatever it is called... the "interactive", Ondemand, powersave etc.
I dont trust interactive scaling atm (had alot of FC on Pinkys and OD 3.5), as it seems relatively new, and still has some kinks.
Sticking with ondemand, with a sampling rate of about 20k and a CPU threshold of about 85%, I have pretty good performance. I have found that upon starting up setCPU on OD 3.5.2, the settings are 20k/11% which could be your problem.
Tried now GeFrost, well the apps icons panel ( 5 pages long...) when sliding again had freezy/laggy feeling....I've wiped GeFrost and installed LeeDroid rom with Sense UI, Now i feel good again I suspect that "none sense UI" Simply not for my touch and feel style... Sense UI feels much more smoother just like DJ droid rom i had...
So my CPU isnt damaged and could not get damaged from what I did... right?
rommark said:
So my CPU isnt damaged and could not get damaged from what I did... right?
Click to expand...
Click to collapse
Your CPU could have been damaged from overclocking - I'm not saying that it has been, but there is always an element of risk when you overclock.
If you really want to overclock, my advice is to always start low and then incrementally increase. If you get to a point where the phone starts to become unstable, drop the speed back down a notch.
Furthermore - not all CPUs are made equal. Just because someone else manages to overclock their CPU to 1384MHz doesn't mean that you will be able to - it's just the luck of the draw.
Regards,
Dave
Hey,
Thanks for your answer.
Well on regular clocks its not freezing up to the level where I need pull off the battary...Something that indeed happened to me on OD with OC.
So far LeeDroid rom works smooth.
How can i find out if my CPU got damaged?
Anyone else had such lock ups which needed battary pull off, with OC on Desire?
Thanks!
Whenever you use a OC kernel, you run the risk of damaging the internals.
Non of the internal components are EXACTLY the same. Some can support lower voltages, some can substain higher Clockspeeds.
My lockups with OD is purely on the SetCPU settings.
Have you got a EXT3 partition on your SDcard? Because I see LeeDroid supports Froyo A2SD, while OD&DeFrost Ports are all LegacyA2SD
This may be the problem, instead of a issue with your internals, as the internals would most likely fail/rapidly overheat altogether if there was a problem.
Well I think my desire is warm as usual... not warmer. Only time it was really warmer then usual. Was when i just installed the OD rom and market was syncing all my massive list of apps all together which i think caused CPU over work but thats was even before i installed set cpu and did any OC....
Anyways LeeDroid now works i think as smooth as DJ droid. without any OC.
As for your question about EXT3 How do i check that? could this cause the lock ups with set cpu while using OD oced?
thanks
ext3 is a linux filesystem partition that you would of installed onto your SDcard, either by RomManager or Linux LiveCD/Linux OS
As your unsure, I'm pretty certain that you have not partitioned your SDcard. With A2SD+ (which are both on the OD and Frost roms), the phone is told to read Apps and delvik cache from the SDcard. This means no applications are actually installed on the phone, but the "internal" memory is now the ext3 partition on your SDCard.
Ext3 is required for both OD and De/GeFrost roms.
With this, it sounds like your CPU is fine, as LeeDroid is running fine, and that you are using Froyo A2SD.
Danifamous said:
ext3 is a linux filesystem partition that you would of installed onto your SDcard, either by RomManager or Linux LiveCD/Linux OS
As your unsure, I'm pretty certain that you have not partitioned your SDcard. With A2SD+ (which are both on the OD and Frost roms), the phone is told to read Apps and delvik cache from the SDcard. This means no applications are actually installed on the phone, but the "internal" memory is now the ext3 partition on your SDCard.
Ext3 is required for both OD and De/GeFrost roms.
With this, it sounds like your CPU is fine, as LeeDroid is running fine, and that you are using Froyo A2SD.
Click to expand...
Click to collapse
Thank you for your kind help.
Should Desire feels warmy in hand during its being connected to computer's USB?
Thanks!
Yea, thats usual. There is still power coming from the computer to charge the battery, so its fine.
I've had my phone hit about 50 Celsius on several occasions, while I've fell asleep ontop of it while playing music, and so far, no visible damage to performance etc
Again, the issues with OD just seem to be based around the lack of a ext3 partition on your SDcard, so don't worry too much about the CPU being damaged.
Just be cautious in the future with OC, and never OC more than you need It can drain more battery, and end up breaking your phone (in extreme cases).
Danifamous said:
Yea, thats usual. There is still power coming from the computer to charge the battery, so its fine.
I've had my phone hit about 50 Celsius on several occasions, while I've fell asleep ontop of it while playing music, and so far, no visible damage to performance etc
Again, the issues with OD just seem to be based around the lack of a ext3 partition on your SDcard, so don't worry too much about the CPU being damaged.
Just be cautious in the future with OC, and never OC more than you need It can drain more battery, and end up breaking your phone (in extreme cases).
Click to expand...
Click to collapse
Thank you so much,
So indeed OD / Gefrost was an EXT3 issue (lock ups, super slow down and lock ups which caused battary pull offs). How can i confirm this?
While DJ droid and LeeDroid working smooth with Sense UI.
thnx!
Only way is to reformat the SDcard, either with Rom Manager which is easiest (available for free on Android Market) or a Linux variant. This will remove all data currently on the SD, so back up everything
Add a ext3 partition to your SDCard (swap size is unnessacary), and install OD/GeFrost.
There will be a major boost in performance compared to previous times.
Hey guys. Anyone found a fix to the lag issue when scrolling up and down in the apps drawer? To know more that I mean, pls click on the below 2 links:
http ://forum.xda-developers.com/showthread.php?t=679037&highlight=scroll+speed
and
http ://forum.xda-developers.com/showthread.php?t=657569&highlight=lag+program+menu+htc+desire
That's strange, I don't experience any lag at all... It's supersmooth and fast.
Ditto, smooth as anything here
Are you using a live wallpaper? one thing i've noticed is cpu intensive live wallpapers make scrolling the apps menu lag quite badly. At a guess i'd say live wallpapers remain running when the apps menu is displayed.
Switch to a static wallpaper or the relatively undemanding htc sense live wallpaper, see if it makes a difference.
Weird..no lag here.
Super smooth.
Yeah, I have a solution for you: buy an iPhone!
Okay, enough trolling. I experienced that as well, but it suddenly stopped and now it's very smooth. I don't know what I did, but I am certain that it stopped after the second 2.2 OTA.
I have a few different ideas you can try. I do all of these on my own phone and it's snappy as anything, even though I've limited the clock speed to 650 maximum.
1) Copy everything back to your phone if you currently have most/all things on your SD card, leaving the things on your SD only if they're actually big. Say, everything below 2mb keep on your phone.
2) Install a different launcher, like ADW. Aside from possibly being a little faster, it allows you to customize your app drawer and remove things you don't need. For example I've removed everything I already have an icon on my home screen for, and now I only use the app drawer for odds and ends or things I'm still deciding if I need them or not - like, 15 things at most usually. I don't even NEED to scroll!
3) Install a better OS, like Cyanogenmod. It's faster in general.
4) Install an OS (or patch/script) which allows you to use an EXT partition on your SD card for apps. EXT2/3/4 are much faster and lower-latency than FAT32.
5) Use SetCPU or a similar app to increase your CPU's MINIMUM speed while the screen is on, from 245 to 384. This will eliminate the initial stutter your phone may have before it decides to clock up the CPU. Even though it's a 50% increase or whatever, in practice it will have virtually no effect on your battery life since it will only take effect while the screen's on - at which time your screen will be using lots more power than the CPU does at any speed.
If #5 solves it for you, just remember the stuttering you're experiencing is only for the sake of battery savings, it's got nothing to do with your phone's performance. In that sense, it highlights one of Android's features rather than a deficiency, even if it's doing this in an unattractive way!
nawoa said:
I have a few different ideas you can try. I do all of these on my own phone and it's snappy as anything, even though I've limited the clock speed to 650 maximum.
1) Copy everything back to your phone if you currently have most/all things on your SD card, leaving the things on your SD only if they're actually big. Say, everything below 2mb keep on your phone.
2) Install a different launcher, like ADW. Aside from possibly being a little faster, it allows you to customize your app drawer and remove things you don't need. For example I've removed everything I already have an icon on my home screen for, and now I only use the app drawer for odds and ends or things I'm still deciding if I need them or not - like, 15 things at most usually. I don't even NEED to scroll!
3) Install a better OS, like Cyanogenmod. It's faster in general.
4) Install an OS (or patch/script) which allows you to use an EXT partition on your SD card for apps. EXT2/3/4 are much faster and lower-latency than FAT32.
5) Use SetCPU or a similar app to increase your CPU's MINIMUM speed while the screen is on, from 245 to 384. This will eliminate the initial stutter your phone may have before it decides to clock up the CPU. Even though it's a 50% increase or whatever, in practice it will have virtually no effect on your battery life since it will only take effect while the screen's on - at which time your screen will be using lots more power than the CPU does at any speed.
If #5 solves it for you, just remember the stuttering you're experiencing is only for the sake of battery savings, it's got nothing to do with your phone's performance. In that sense, it highlights one of Android's features rather than a deficiency, even if it's doing this in an unattractive way!
Click to expand...
Click to collapse
I have my Desire set at 768 max and there really isn't a noticeable difference from the normal 998. Hell. I clocked it way down and it was still WAY faster then my HTC Magic ever was. It's funny that the Desire's processor is faster at 3xx mhz then the Magic's is at 710mhz. I found the Desire to be unstable for sustained periods of anything under 700mhz though. Is yours running stable at 650? Maybe it was just the 691mhz speed I was using.
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
MOD IS FOR ANDROID 4.1.2 FOR T-MOBILE NOTE 2 ONLY. DO NOT USE WITH CM. CHANGE LOG AT THE END OF THIS POST
SYSTEM DATA AND CACHE ARE NOW WORKING 100%. ALSO, PLEASE SEE POST #72 FOR FURTHER INSTRUCTION ON SETTING UP YOUR CPU PROFILES APPROPRIATELY TO INCREASE STABILITY AND PERFORMANCE
BIG bug fix in aroma... we have figured out what is causing boot loops. The issue is that twrp is mounting data as ext4 after the mount command is executed. This is an issue with twrp, not aroma. Instructions at the end of this post on how to get around this until we figure out how to cause this not to happen...
As of right now these modifications are only being provided to you for touch wiz. I will not provide links to CM based kernels simply because is more prone to being unstable. Do this mod on CM on your own, and at your own risk. Again, kernels in this thread are touchwiz based, and will not work on CM ROMs.
First of all, let's talk about file systems.
ext2 - (second extended file system in linux) is different from ext3 and ext4 in the sense that it does not use something called journaling. There are other differences as well, but for the sake of showing what kind of performance improvements this file system provides over the latter two (3 and 4), we'll cover what is relevant to us Android users. Data is directly written to a disk as it comes through on ext2 devices.
ext2 does have file limitations compared to ext4. ext4 uses pre allocation of blocks and delayed allocation of data writes and also organizes data a little more efficiently on inodes/blocks. It also has a way to "mark" unused blocks, this reduces IO search times. ext4 also uses a checksum in the journal to improve reliability since the journal is one of the most used files of the disk. In a nut shell, journaling is an overhead feature of ext4 that ensures file/data integrity. This is useful if a system is not shut down cleanly, or the stability of the system has been compromised in some way. And even THAT being said, ext4 has it's own unique issues with data corruption through the delayed allocation feature. Furthermore, and probably the most important to note, those features are really only useful when you have extremely large disk sizes in the exabyte or terabyte range. Our devices are INCREDIBLY small in disk size. ext4 really only outshines ext2 in performance when you are dealing with large databases (and 16 GB, partitioned, is not large... at all). The point to bring up here is that ext4 is only used on these devices out of the factory for total stability. The devices were not designed out of the factory with the advanced user in mind, they were designed with the everyday person soccer mom who needs a "safe" device that will take and handle all kinds of beatings and abuse. The cost for that, unfortunately, is performance. So let's fix that problem.
Here is some more info about it online, an extremely informative article of some test data samples of different files systems in Linux, and their performance.
http://mindplusplus.wordpress.com/2012/01/11/finding-the-fastest-filesystem-2012-edition/
This thread is going to show you guys how to convert your file systems to ext2.
First of all, let's address some useless init.d scripts that I have seen littered all over ROMs to "optimize" ext4.
Code:
tune2sfs -o journal_data_writeback /dev/block/mmcblk0p13
tune2fs -O ^has_journal /dev/block/mmcblk0p13
mount -o remount,noatime,noauto_da_alloc,nodiratime,barrier =0,nobh /system
and so on and so forth for the other two partitions (cache and data)
Now, to be fair, the implementation of this code is not utterly USELESS per say. It does provide a very small amount of IO performance increase. However, this fact still remains:
The op paths in the fstree are optimized for the journal, so simply disabling it makes the code path redundant. And furthermore, the journal-optimized block sizes now have empty overhead (basically you are still using the exact same amount of disk space). On top of that, the performance increase really is not noticeable. Therefore, it is not worth the trouble. And most of the time these "hacks" are tossed into /etc/init.d/ and the user comes alone not knowing to make a back up after flashing this ROM, or has no clue what these actually do (and sometimes the dev doesn't quite understand it either).
ext2's strength is it's simplicity, which goes well with "noop" IO scheduling if the fs itself relies on virtually NO ops. As it comes through, so it is done. The performance benefits of this are absolutely unreal you guys. Your device that used to boot in, say, 30 seconds? - Now boots in maybe 10. That is the real time performance difference we are talking about here. Cut out all the hoopla of ext4.
For those of you who are saying "well what about stability??" my answer is simply this: if you refuse to make a back up of your data and system (recoveries are called recoveries for a reason) you are simply doing yourself a disservice. I have been using ext2 file systems for a long time now, and let me tell you - never will that change. You just can't beat the performance, and the reliability is as sound as you make it - if you are one of those that feels the need to run your processor on performance all day at 2.4 GHz, well you are bringing about your own problems. BUT, like I said, even for the extremist, JUST MAKE A BACK UP OF YOUR DATA!!!! - gravy. :good:
DIRECTIONS>>>>
1.Download and flash your ROM of choice. Or if you have one installed that you like, just boot to recovery and proceed.
2.In TWRP, make a backup of your /system and /data, do not enable compression, just do it how I did it and save yourself some potential headache. If your backup gets ****ed. It’s time to reflash from scratch.
3. Since you will be wiping data, your backup cannot stay on your internal SD. So boot back up, and copy that SOB to your desktop computer. It should be in your internal storage under a directory named “TWRP”. Open it up and COPY, do not cut, the “BACKUPS” folder to your computer and/or external SD card… also, verify both of your backups are actually in that folder before you proceed. There will be one for system and data, and a couple of md5 files, some logs, etc etc… a handful of files. Also, download the two kernels attached in this thread … “TNT-ext2_sys_TMO-TW23-600” and “TNT-ext2_sys_cache_data_TMO-TW23-600” and put them on your EXTERNAL SD CARD. INTERNAL SD IS NOT AN OPTION BECAUSE IT WILL EVENTUALLY GET WIPED IN THIS PROCESS.
4. Boot back to recovery, go to settings, and change the format option to “format using rm –f” ALWAYS ALWAYS ALWAYS FROM THIS POINT ON MAKE SURE THAT IS CHECKED EVERY TIME YOU GO TO RECOVERY
5.After you do that, go back to TWRP main screen, select “advanced” and “terminal” or whatever… it will ask you for a starting directory. Just make sure you are at root, then hit the little button on the bottom that says “select”… it will then take you to a terminal session.
6.From terminal, type the following command then hit enter or “GO”
Code:
“mke2fs /dev/block/mmcblk0p13” (without quotes)
MAKE SURE YOU TYPE THAT CORRECTLY! CANNOT STRESS THAT ENOUGH 0p13 0p13 0p13 0p13 0p13 0p13 0p13 0p13 0p13 ZERO P THIRTEEN SAY IT IN YOUR HEAD
Let it finish. It will only take a couple seconds.
7.After it is done, hit the back button until you are on the main screen on TWRP again… and just for good measure, again verify in your settings that “format with rm –f” is checked. Now go back and select “restore” from main MENU in TWRP. Restore your system backup only.
8. After that is done, flash the “TNT-ext2_sys_TMO-TW23-600” kernel.. again, make sure this is not the sys_cache_data version. Your other two partitions are not formatted yet.
9. REBOOT! Enjoy your system on ext2 and battery and performance improvements. If you only want /system as ext2, stop here. If you are the extremist, and want data and cache optimized as well, proceed.
10. Since your internal storage such as downloads, zedge files, whatever else you have on there, is going to get wipe during THIS phase…. Please make backups accordingly. Your entire internal storage is going to be reformatted – Again, prepare accordingly by backing it up to your external SD card or a desktop computer.
11. Boot back to recovery, at this point your system is already ext2, cache and data are still ext4. So here we go. And I will take you through the long process but the safest.
12. From Recovery MAIN menu, select “MOUNT” and uncheck the boxes for cache and data. Go back to main menu.
13. From recovery MAIN menu, select advanced again, (PLEASE FOR THE LOVE OF HADES AGAIN MAKE SURE YOU HAVE BACKUPS OF YOUR STUFF… if you come crying in here about “hey my downloads and zedge ringtones were wiped wtf bro” I will ignore you and wish death and damnation upon you, you noob. So just don’t do that. Make backups before proceeding)… ok, so again after hitting advanced, select the terminal again, make sure you are at the root directory, hit that little select button. You are now in another terminal session.
14. From terminal, type the following commands (WITHOUT QUOTES and hit enter after each one)… and please again for the love of EVERYTHING HOLY TYPE THIS CORRECTLY AND DOUBLE CHECK CORRECT NUMBERS ARE PUNCH IN AFTER “p” … have this page open while doing this. Look at it, and then look at it again. This is pretty straight forward stuff guys, but a small mistake can be detrimental. So please pay attention.
Code:
“mke2fs /dev/block/mmcblk0p12” <--this is the cache partition
“mke2fs /dev/block/mmcblk0p16” <--this is your data partition, including internal SD.
Now we need to manually create your /data/media/ directory… because it is gone right now buhbye. Rofl
Again, straight forward… without quotes… you get the idea by now
Code:
“mkdir /data/media”
BOOM.
15. Go back to TWRP MAIN menu, and flash “TNT-ext2_sys_cache_data_TMO-TW23-600”
16. Reboot.
17. Success! You are now on ext2 file systems for /system, /data, and /cache.
At this point you have 2 options. After your device reboots, you will be asked to sign back into your google accounts, etc etc etc… data was wiped, so you are at square 1 again with your particular setup. If you wanna set up real quick (like say you are the simple type that just has a few apps, not a whole lot of work to get back to where you were, etc) then maybe a restore isn’t really necessary. You decide. If you neeeed your bajillion million apps restored, no problem. Continue reading.
18. Hook your device up to your PC, find your internal storage. There should be a directory there named “TWRP” if it isn’t there, simply create it.
19. Grab that “BACKUPS” folder and drop it in the TWRP directory of your internal SD.
20. Reboot to recovery.
21. GO TO SETTINGS AND VERIFY “format with rm –f” is still checked… otherwise you are starting this whole instruction over again. Lmaooo… happened to me last night. I’z like…..fakk.
22. All good? Ok now go back to MAIN menu, select restore, and restore both system and data
23. After that is done, MAIN menu… just for good measure…. Select WIPE, then ADVANCED WIPE… and wipe ONLY CACHE once… two… times…. 9 times… whatever tickles your pickle people I’m OCD so even though I know doing it more than once is redundant and unnecessary I do it twice.
24. REBOOOOOOOOOOOOTTTTTTTT
Well wasn’t that fun? Now always keep a backup of your system and data handy (just in case you ever need it, or you have a lockup, whatever the case may be where you feel like your system has been compromised) and you will be a-ok. I’ve personally never had issues with this.
Enjoy.
Download links for modified kernels are up! See below... Thank you morfic for allowing me to post copies of your kernels here. Only things changed are mount points to accommodate the new ext2 paritions. His git is here>> https://bitbucket.org/morfic/note2-tw
UPDATED WITH fsck DISK CHECK FOR INIT.D.... remove the ".txt" extension and drop this file into /etc/init.d and give it full permissions.
Instructions for flashing with aroma installer***********
1. Put aroma installer on external SD card
2. Boot to recovery (make sure you have already flashed the ROM you want to use)
3. Once you are in recovery, make a back up of your current system using the twrp method and CHANGE THE BACKUP LOCATION TO YOUR EXTERNAL SD CARD. Then going into settings, and check the box that says "format using rm -f" or whatever it says... you'll see it once you are there. MAKE SURE THIS IS CHECKED! EVERY TIME you go to do this. The only time you should uncheck this option is if you are trying to revert back to ext4.
***Cannot stress #3 enough you guys, it was the reason you were all boot looping. If you come back here saying you are boot looping, I will e-slap you so hard your face will actually hurt. We will raise up armies against you and those around you. Carnage will ensue. Ok maybe not.... but just make sure every time you go into recovery to do something with this aroma installer that you check that box. EVERY TIME... because sometimes it unchecks itself.
4. Well, easy enough. Now flash the installer. Only use it to convert /system for now, and use the manual method (above) for /data
You can try doing data through the aroma installer, just make sure you check that box in settings of twrp before you attempt to do so.
"That was easy."
AROMA INSTALLER FOR EXT2
http://tweaked.mediafire.com/download/ody7u8wxzarjv37/ext2inizer.zip
md5 = EB0EB296B06DF5BEFFAA26D1D39291DA
Seem appropriate to start a change log for this.
July 19, 2013
Stock kernel added as an option in aroma for those who cannot run morfic
No more options in aroma to only do /system. You now can only do all 3.
July 18, 2013
K this should be nailed down now.
July 17, 2013
1. Bug found. Boot looping issue has been identified and pinpointed. See flashing instructions. (above)
July 16, 2013
1. Misc code fixes in aroma (more like optimizations really) for the backup logic
2. fsck script for init.d updated - calls to /system/xbin now
3. Some more manly stuff
Previous Versions
1. Initial release and various small optimizations with aroma
Great write-up. Interesting info
Sent from my SGH-T889 using xda app-developers app
So much reading
Sent from my SGH-T889 using xda premium
Just a quick update on this… I want to give you guys an idea of just how much overhead is generated by your ext4 file system.
Right now I am currently sitting at 87% battery, 5 hours off the charger, and 1 hour and 3 minutes screen on time.
This is only with /system mounted as ext2. /data and /cache are still mounted as ext4.
To give you a comparison (and my usage throughout the day is 100% consistent, so I am a good test model for this particular thing) 5 hours off the charger, at 82%.... I am usually looking at about 50 minutes of screen on time.
In short, simply changing my /system partition to ext2 has saved me 5% battery at this point in my daily activities, while still gaining 12 minutes of screen on time.
So converting that….
Improved screen on time by 25%, and overall system usage and battery drain has improved by about 60%
That is just /system
EDIT** screen of /cache successfully mounted as ext2
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hi I am looking for a long time to convert my SD card and my system to Ex format because I cannot use my 32 gb sd card efficient for example my limit is 5gb would that fix my problem?
Since you like to convert between filesystems, do us all a favor and run Bonnie++ on them.
http://forum.xda-developers.com/showthread.php?t=1169910
Maybe there is a noticeable difference on Note2 hardware, but in the past, it hasn't been the case. To keep things "even", run from adb shell in recovery. That way you don't have the pesky OS overhead etc... Just format a partition, run the test, copy/paste the results, format and run again.
Now, that IS a benchmark and all the usual benchmark caveats apply, however, it is also a useful start to determine how the hardware handles the various cases.
Speaking from experience on previous phones, particularly the Samsung Vibrant, the speed difference wasn't really noticeable. You could see it in benchmarks, but in real life, if I were to write a boot script that would randomly change them back and forth, 99% of users would never notice. Now, the downside of ext2 did rear it's ugly head a few times, with users getting stalled boots and having to run fsck at boot after a crash, or power loss. Complete filesystem loss is possible in theory, but I've never seen it, so let's just discount that one. Early mods didn't account for needing to run fsck and would stall the boot, to the user it looked bricked. If you do end up needing fsck, it can make those "long" ext4 boot times look pretty fast..... However, none of the failure scenarios are really all that likely, so let's stick to performance.
As I said, Note2 hardware is different. Just putting the past out there. This is OLD ground. Perhaps the hardware makes all the difference..... From some of the previous testing back in the day, JFS and Reiser looked like good candidates for phones.... I don't know if anyone ever actually tested running Android on them though.
patches said:
Since you like to convert between filesystems, do us all a favor and run Bonnie++ on them.
http://forum.xda-developers.com/showthread.php?t=1169910
Maybe there is a noticeable difference on Note2 hardware, but in the past, it hasn't been the case. To keep things "even", run from adb shell in recovery. That way you don't have the pesky OS overhead etc... Just format a partition, run the test, copy/paste the results, format and run again.
Now, that IS a benchmark and all the usual benchmark caveats apply, however, it is also a useful start to determine how the hardware handles the various cases.
Speaking from experience on previous phones, particularly the Samsung Vibrant, the speed difference wasn't really noticeable. You could see it in benchmarks, but in real life, if I were to write a boot script that would randomly change them back and forth, 99% of users would never notice. Now, the downside of ext2 did rear it's ugly head a few times, with users getting stalled boots and having to run fsck at boot after a crash, or power loss. Complete filesystem loss is possible in theory, but I've never seen it, so let's just discount that one. Early mods didn't account for needing to run fsck and would stall the boot, to the user it looked bricked. If you do end up needing fsck, it can make those "long" ext4 boot times look pretty fast..... However, none of the failure scenarios are really all that likely, so let's stick to performance.
As I said, Note2 hardware is different. Just putting the past out there. This is OLD ground. Perhaps the hardware makes all the difference..... From some of the previous testing back in the day, JFS and Reiser looked like good candidates for phones.... I don't know if anyone ever actually tested running Android on them though.
Click to expand...
Click to collapse
Well, I wouldn’t really call this benchmark irrelevant… but it is certainly not needed because the logic and theory behind the two file systems is sound and proven.
Of course you are not going to SEE a difference when opening, say, your messaging app even tho it is mounted to an ext4 system. But the performance benefits are still there, the reduced IO operations on your disk are real (that is reflected in battery life, as I mentioned above), and your boot times being faster is also a real time that you can see. Less cpu cycles, less overhead, more efficient. The operation is still taking place, is what I am saying. And having a powerhouse processor like these that uses more juice to complete a task than the devices of old (two years ago, rofl) is all the more reason to optimize as much as possible.
As far as the “instability”, like you, I have not personally experienced any of the horror stories of data corruption or a total system loss at a catastrophic level, nor have I ever had problems simply booting the device.
All I can say is this fact remains: ext2 > ext4 when it comes to performance. My whole idea behind this stems from the fact that as root users of these machines, we have the luxury of backups, and therefore we have no reason to not run a truly optimized (performance-wise) file system. Ext4 is a waste of disk space and cpu cycles on these devices.
Just my opinion of course. I’ll run the benchmark, however, just because I am curious to see what it says.
b rrrrr bbbb
This is work is for all kernels?
Sent from my SGH-T889 using xda premium
jpeps said:
This is work is for all kernels?
Sent from my SGH-T889 using xda premium
Click to expand...
Click to collapse
This will work for all kernels that support ext2 (most should)
It will still require you to change the mount points, however. That I cannot do for you.
Updated.... Successfully mounted ext2 file system for /data/
Holy monkey balls r/w speeds are nuts. Device booted in about 15 seconds.
I'll have a battery stat report tomorrow...
Please make video how to do this or how to
Thanks
Sent from my SGH-T889 using xda premium
Admiral Sir Manley Power said:
Well, I wouldn’t really call this benchmark irrelevant… but it is certainly not needed because the logic and theory behind the two file systems is sound and proven.
Of course you are not going to SEE a difference when opening, say, your messaging app even tho it is mounted to an ext4 system. But the performance benefits are still there, the reduced IO operations on your disk are real (that is reflected in battery life, as I mentioned above), and your boot times being faster is also a real time that you can see. Less cpu cycles, less overhead, more efficient. The operation is still taking place, is what I am saying. And having a powerhouse processor like these that uses more juice to complete a task than the devices of old (two years ago, rofl) is all the more reason to optimize as much as possible.
As far as the “instability”, like you, I have not personally experienced any of the horror stories of data corruption or a total system loss at a catastrophic level, nor have I ever had problems simply booting the device.
All I can say is this fact remains: ext2 > ext4 when it comes to performance. My whole idea behind this stems from the fact that as root users of these machines, we have the luxury of backups, and therefore we have no reason to not run a truly optimized (performance-wise) file system. Ext4 is a waste of disk space and cpu cycles on these devices.
Just my opinion of course. I’ll run the benchmark, however, just because I am curious to see what it says.
b rrrrr bbbb
Click to expand...
Click to collapse
Fewer instructions doesn't necessarily == greater performance. There was a lot of time between ext2 and ext4, a lot of work was done on the underlying code in that time. In many tests, ext4 reads out-perform ext2. As the storage is by far the slowest part of any computer, using a few CPU cycles for better caching etc. is often well worth the tradeoff. Performance of the two is by no means a given, this was hotly debated long ago and the same issues remain. I'm an open minded sort of person, so I'm not saying it isn't possible that it makes a bigger difference now.
One note... while current CPUs use more power at the higher clock speeds, they also complete the tasks faster, and thus, spend less time at higher clock speeds, getting back to sleep faster than older CPUs. Modern chips also have features that older chips did not, like sleeping individual cores. There are a LOT of variables at play, it's never as simple as that.
ttabbal said:
Fewer instructions doesn't necessarily == greater performance. There was a lot of time between ext2 and ext4, a lot of work was done on the underlying code in that time. In many tests, ext4 reads out-perform ext2. As the storage is by far the slowest part of any computer, using a few CPU cycles for better caching etc. is often well worth the tradeoff. Performance of the two is by no means a given, this was hotly debated long ago and the same issues remain. I'm an open minded sort of person, so I'm not saying it isn't possible that it makes a bigger difference now.
One note... while current CPUs use more power at the higher clock speeds, they also complete the tasks faster, and thus, spend less time at higher clock speeds, getting back to sleep faster than older CPUs. Modern chips also have features that older chips did not, like sleeping individual cores. There are a LOT of variables at play, it's never as simple as that.
Click to expand...
Click to collapse
While I agree with some of what you said, the fact of the matter is ext2 out performs ext4. Mostly because even though ext4 has all of these nifty little pre-allocation for blocks, and inode/block numbering, and even a function in place to mark blocks that are not being used so it knows where exactly to search when a request is made on the disk (this is where that read performance comes in that you speak of)... it is still slower because of journaling. And you still have overhead IO operations. And disabling journaling doesn't fix that entirely, it just makes it more unstable.
HOWEVER... you are still wrong, and whoever debated that ext4 outperforms ext2 on these devices, was also wrong. Let's break this down a bit. So you can understand where my logic is coming from to make that conclusion.
First of all, I will say this, and it is fact. The ONLY reason google switched to ext4 was because they needed a file system that could handle MUCH MUCH larger disks. ext4 has far greater file capacities, and also overall disk capacity than ext2. We are talking exabytes, terabytes, not measily 16 GB devices such as these.
A full odexed ROM on this device, for example, has a total of about 1900 system files, it is less if you are de-odexed (dex files are moved to /data/dalvik-cache). ext2 has an overall file subsystem limit of 32,000, I believe (off memory please correct if I am wrong) and ext4 has some number ridiculously higher than that... I think it is actually 64,000 if I'm not mistaken. Why is this relevant? Because the ONLY reason ext4 has ALLLLLL those cool little extra overkill organizing features is because it is designed to handle data and file clusters that are literally 100 times larger (or even more) than a measily little Android OS that takes up 1.2 GB of space on a 1.7 GB partition ... ext4 is overkill for these devices and the only reason it is implemented by Samsung and Google is because they want it to be as reliable as possible. The average user will not know how to make a backup, root, or restore a backup if something goes wrong.
ext2 is simple and fast. The fact that it was developed years ago doesn't mean anything. "Improvements" in these types of things are most of the time brought about by some type of demand, not necessarily because it is faster or more efficient. In ext4's case, the demand was larger storage devices and a rock solid stable file system.
If you need another reminder of proof.... again read my reports of boot times and battery life. That should be enough evidence to undo whatever you may have read in the past about what is best for either.
Apply applications and modifications as necessary. I'm not running warehouse full of servers... it's a handheld computer with a very small operating system and disk. ext2 will outshine ext4 in any application like this.
Were I running servers, though, or were I Google.... yeah.... I'd probably be looking at ext4.
Just because the device was delivered to you with this or that, doesn't mean it is the best or fastest in that condition. Variables, again, were developers taking into account the every day user. Thus, they decided on ext4. You and I, are not the every day user.
I think it's time I leave this thread, you seem to be getting worked up over my little posts. I'll try once more though...
Search my history, I've done a LOT of work on various filesystem based things. Remember my mentioning the Vibrant? I contributed to Project Voodoo and did other related mods back then. ext2/ext3/ext4 with various options, installer based stuff, etc... And, from experience, on that particular phone, the day-to-day difference was very small. As I said, the Note2 is a very different beast, but the various filesystems haven't changed that much. I'll probably test your mod when there's an installer, I don't have time to fiddle with formatting everything myself these days.
As for battery life, I was leaving it alone as I considered it off topic.... The Android battery meter simply isn't accurate enough for the comparisons you are talking about here. It's an educated guess based solely on the voltage at the moment. Connect a logging ammeter inline and you might have something to go on. But the % meter is a red herring for any other comparison.
Boot time, well, I did say I thought it could be faster. The question is one of degrees. Frankly, the boot time isn't really that interesting... I don't boot my device that much.
What I care about is performance in general use and, to some degree, just pure faster I/O. As I mentioned, it's the slowest part of any system, making it faster is always nice. The system loads during boot are kind of a special case... What I care more about are things like how fast I can push records in/out of a sqlite DB from my app, copy files about, etc.. I suspect it will be faster on ext2, particularly for writes, the question is how much? Is it enough that I would notice on a daily basis? And yes, it depends greatly on the user, what apps they have installed, running in the background, various system options that would use memory, state of the cache, etc... But if it is a significant boost for the general case, it should be noticeable to the user.
There is also the error case... if you are writing to the FS and pull the battery.... what happens? ext2 gets angry when you boot. ext4 replays the journal, you might lose data, but you don't have FS issues and it doesn't refuse to mount until you run fsck on it. Now, it's possible ext2 has improved some since then, but do you have a boot check to ensure it's not an issue? You should if you want a general use setup. I'd rather have the device stall a bit while booting and run an automated fsck than just refuse to boot. As I said, this situation isn't common, but it was one we ran into back in the day, so I'm mentioning it for the sake of any users that follow your steps or use any flashables you set up. Please do include an init.d script to handle it. You can find some in the various mods from back then. I don't think people were losing data, but really, it's simple to just check for it and fsck at boot time. The fsck issue and the fact that the performance difference wasn't huge, led most to just use ext4 as it was faster than ext3 and didn't require boot checks. But, as they say, that was then. The situation could have changed. I'm curious to see what comes of this. Don't take me the wrong way, I'm trying to provide info so you don't end up getting caught on stuff I've seen before. And in typical user fashion, if this happens, you will have people coming here yelling that you bricked their phone, blah, blah, blah.
And now you see why I don't do much dev stuff on here these days. Good luck though.
Lol... Bro I'm opinionated and although I disagree with much of your statements, particularly about battery life and so forth (which isn't a percentage based on a bunch of different variables, it is actually quite simple and pretty accurate - x volts = x % ... Not hard to compute... Its also pretty straight forward logic, and monitored by the kernel, relayed through the OS... easy), don't take it as anything personal. I enjoy the back and forth technical conversation.
If you are running a note II, though, you should give this a shot. Really and truly I believe you'll have a positive experience with it.
I'll make a script later for init.d so we can reduce issues even more. I used to run ext2 "back in the day" as well and personally had no issues with it whatsoever. The key is to run a stable kernel, though, to be honest. There is no reason to not be able to run your device cleanly for weeks on end without a lockup or reboot. That is key, stable kernels.
Give it a shot, and see for yourself.
And stick around here... And share your insight. Seriously
Any luck on the kernels i cant find the download for them?
HOGWILD said:
Any luck on the kernels i cant find the download for them?
Click to expand...
Click to collapse
Yes waiting to hear back from a dev about posting his work here. He is a friend of mine, but he is also busy.
Updated OP with an fsck script for init.d... this is going to slow your boot times a bit, but very much worth it. Thanks tabbal for the suggestion (a good one indeed).
Still waiting to hear back from morfic about his kernel... I dont think he will have a problem with it but I respect him and his work, so we'll have to wait.
EDIT*** links are up, thanks morfic...
LIKE A BAWS
OK.... So here is my battery update....
16 hours off the charger...
48% left....
4.5 hours screen on time...
Ummm. Yeahhh... Lots of unnecessary CPU usage going on under the hood on ext4 I would say. That is a HUGE difference from what I typically see. Almost an hour if screen on time gained.
Cool
Dose it work on all kernels ???
Sent from my SGH-T889 using xda premium