Database Develop

Nexus 7 Grouper Custom ROM Memory Usage Comparrison

Hi all
I very much doubt this post belongs here, but since i am a new member , have no chice but to put it here.
I have recently accidentally purchased a nexus7 (grouper) and decided to try some of the custom roms available, in the end i tried most of them.
Here are my comparison results.
As with all things putting an "order" on the roms is subjective, the "best" rom is the one that works for the individual,with that individuals particular needs and wants.
As an embedded design engineer i am obsessed with speed and efficiency, memory usage, putting as much data on the screen as possible, then finally compatibility and lack of bugs ( in that order ), my results are biased by that order.
Disclaimer........
1) Ok i know that android is not exactly ideal if looking for an efficient well written os ( who the F came up with the idea of running everything in a VM!!! a minimal linux system will run in 85 mb ram with a full xserver, android STARTS at 400mb+, sitting there doing nothing !!!, thats near my cut down windows7 running on an i7 ) but before a decent linux distro is ported to full touch am stuck with it
2) For the N7 the requirement to change the DPI is essential, it is VERY stupid that the os does not check and change this automatically, otherwise its like having your 1920x1080 monitor stuck on 1200x600 permanently, very stupid !!! So am assuming the roms without this facility will function at 160dpi correctly, i have not been able to check this for every rom
All roms were flashed by TWR ( latest ), wipe of cache, dcache, factory reset, system
Memory was checked by settings>apps>running , immediately after first boot, then after a clean reboot, then after a cache,dcache wipe and clean reboot
IMPORTANT NOTE.....
Google apps ( gapps)...... in terms of memory usage gapps is the worst peice of #%%#%%$#$% sh$%^%$%t bloatware i have ever encountered in my os experience ( and given that i spend most of my time in windows, that saying something ).
On any of the roms i have tried flashing gapps adds at LEAST 150mb of unneeded memory usage, and depending on the rom that can go up to 250mb. Even using a minimal gapps with only phonesky,framework,login and setup, still produces a significant 50+mb hit, unfortunately in many cases some of gapps is essential, and some os functions are broken without at least the framework.
This situation seems unacceptable to me, all the roms should function correctly without gapps, and without the bloat, if some dev does not address the situation i will.
1) Prime Grouper D03-06
Tablet ui...... yes
DPI changer ...yes
Size custom nav bar ....yes
Speed....... good
Response ... good
This is first on the list for 1 good reason, memory usage!!!
Before flashing any kind of gapps
First reboot 360mb
Second reboot 320mb
Cache wipe reboot 270mb
Subsequent reboots 266mb ( stable )
Obviously team Vanier know their sh**t, their os is running in nearly HALF the memory space of other roms , and on the whole with few bugs, but whats really impressive is the memory usage is incredibly stable for a android os, zero memory leaks, leave the device at 302 mb ( say you opened an app and it was cached etc ) for 24 hours check again and lo and behold its still roughly 320mb ( obviously internal processes are moving this number a little but only by <>5mb ), this is not the case with stock rom or many other custom roms.
Everything is not all roses though, using prime without flashing gapps at all, exposes quite a few bugs, notification panel does not work at all, clock settings is broken, a few apps fail ( mx player fails for a start ) and others.
Flashing a super minimal gapps, fixes most of the issues, notifications are back, a lock screen turns up, all the settings appear fixed, BUT it also knocks out vanires keybord and totally ruins the memory handling
After flashing "micro" gapps ( and going through setup, adding valid account etc )
First reboot 430mb
Second reboot 360mb
Cache wipe reboot 320mb
Subsequent reboots 360mb ( NOT STABLE, can vary up to 400mb+ with time )
Obviously would love to see PRIME fix the outstanding bugs, and produce a custom set of gapps apk's that dont screw this fine rom.
2) Smooth ROM v5
Tablet ui...... yes
DPI changer ...no
Size custom nav bar ....yes
Speed....... good
Response ... excellent ( the best )
Gapps are included
First reboot 470mb
Second reboot 4200mb
Cache wipe reboot 400mb
Subsiquent reboots 440mb ( NOT STABLE can go 500mb+ )
This rom is second due to a totall lack of bugs, after much mucking around i can not find a single setting or feature that does not work correctly, plus the UI is very very responsive, the best of all i have tried. It would be top but for the lack of a DPI change option and the fact that memory usage is nearly double that of PRIME.
will post the other 20 odd results later

What's more interesting is that identical apps on the galaxy S3 take up 2-3 times more memory. 1GB is fine on the N7 but you have to do a lot of fiddling to get the S3 running with 1GB. Must be down to the Tegra architecture. Smooth 5 runs great on the N7 (especially with greenify app)
Sent from my Nexus 7 using XDA Premium HD app

3) Cookies_Cream-1.3.1
Tablet ui...... yes ( built in as standard )
DPI changer ...yes ( 160 dpi native )
Size custom nav bar ....yes
Speed....... ok
Response ... ok
Before Gapps
First reboot 560mb
Second reboot 560mb
Cache wipe reboot 560mb
Subsequent reboots 560mb ( stable )
Although a memory hungry beast this rom is optimised for the n7 resolution AS STANDARD, you get full true tablet ui, AND with the PARANOID ANDROID framework, it is ultimately compatible with any app at any resolution, and best of all it all works!! no bugs that i can see, although memory use is very high at least it is quite stable before gapps.
If you want the full tablet experience out of the box then consider this.
I have not tried a memory test after gapps, 560 was too high for me without gapps let alone with
4) BeatMod_CrystalClear_v2.3.zip
Tablet ui...... yes
DPI changer ...no
Size custom nav bar ....yes
Speed....... good
Response ... good
Gapps are included
First reboot 480mb
Second reboot 4100mb
Cache wipe reboot 400mb
Subsequent reboots 440mb ( NOT STABLE can go 500mb+ )
being pure CM10 this one is very different in style to the AOKP based roms, but is almost identical to smooth rom in terms of memory usage, although less responsive, on the up side is packed full os sound enhancing mods and an upgraded bravia engine for video
the rest are in no particular order

gsw5700 said:
What's more interesting is that identical apps on the galaxy S3 take up 2-3 times more memory. 1GB is fine on the N7 but you have to do a lot of fiddling to get the S3 running with 1GB. Must be down to the Tegra architecture. Smooth 5 runs great on the N7 (especially with greenify app)
Sent from my Nexus 7 using XDA Premium HD app
Click to expand...
Click to collapse
jesus am wandering how 512k devices ever ran !!!, android MUST have gotten a lot more bloaty since the 2.x days, otherwise nothing would have worked !!!

jubei_mitsuyoshi said:
jesus am wandering how 512k devices ever ran !!!, android MUST have gotten a lot more bloaty since the 2.x days, otherwise nothing would have worked !!!
Click to expand...
Click to collapse
You got it! There's a huge difference between the gingerbread days and now, i remember when my droid eris would use 200 megs of ram for the OS, now.....its a lot more. Why do you think new devices are getting 2gigs of ram, I'm guessing key lime pie will only use more and more memory to give us a better experience
Sent from my Nexus 7 using xda app-developers app

Triscuit said:
You got it! There's a huge difference between the gingerbread days and now, i remember when my droid eris would use 200 megs of ram for the OS, now.....its a lot more. Why do you think new devices are getting 2gigs of ram, I'm guessing key lime pie will only use more and more memory to give us a better experience
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Hmm have to take your word on better experience having just come to android.
PRIME runs at 266mb without gapps, thats a bloody good number for android, just needs the bugs fixed and a minimal/mico ( just playstore functionality, without the paid service ) gapps integrated so all the settings etc function, then we are talking as good as it gets with android.
Generally if you want something doing do it yourself but in this case am in the middle of becoming proficient in c/c++ ( again , its amazing when buried in hardware, pcb design, spice sims, matlab etc etc that one can just forget how to code, i always thought it would be like riding a bike WRONG! ) so learning java from scratch is out for at least 6 months, am very much in hope that PRIME does it for me ,

Before you go any further you should define exactly what you mean by "memory usage".
I challenge you to correlate your "memory usage" statistic to anything you can find in /proc/meminfo.
Go ahead, give it a try.
In any modern OS - including Android - 100% of DRAM is in use. The only thing which remains is some quibbling about whether you should give up file cache space for process memory space or kernel private memory, and the answer to those questions always depend on the nature of the workload.
The whole of dalvik is built on top of native shared libraries that are substantially smaller than the totality of shared libraries present in (let's say) a recent Linux distro. They can be memory mapped in copy-on-write or read-only fashion to a large number of process spaces, and so in fact it is a strategy of the "system_server" process to preload most of them. That way new activities spring to life quickly, rather than being required to demand-load and link everything from scratch.
Bottom line: it is an intentional strategy of android to "use up memory" right from the get-go. Most of that "used memory" is shared libraries that are mapped into activities as they come and go.
So, would I want to run engineering applications that require 800 MB of heap space on an android OS tablet with 1 GB of RAM? The answer is clearly "no" in that case, but mostly because Android devices are not targeted for that kind of work.
For comparison, BTW, my Win 7 x64 box that is nearly bare of applications (I only use it as a VM host) needs 1 GB of committed page space to sit there and do nothing. Android isn't doing so badly in comparison.
cheers

bftb0 said:
Before you go any further you should define exactly what you mean by "memory usage".
I challenge you to correlate your "memory usage" statistic to anything you can find in /proc/meminfo.
Go ahead, give it a try.
In any modern OS - including Android - 100% of DRAM is in use. The only thing which remains is some quibbling about whether you should give up file cache space for process memory space or kernel private memory, and the answer to those questions always depend on the nature of the workload.
The whole of dalvik is built on top of native shared libraries that are substantially smaller than the totality of shared libraries present in (let's say) a recent Linux distro. They can be memory mapped in copy-on-write or read-only fashion to a large number of process spaces, and so in fact it is a strategy of the "system_server" process to preload most of them. That way new activities spring to life quickly, rather than being required to demand-load and link everything from scratch.
Bottom line: it is an intentional strategy of android to "use up memory" right from the get-go. Most of that "used memory" is shared libraries that are mapped into activities as they come and go.
So, would I want to run engineering applications that require 800 MB of heap space on an android OS tablet with 1 GB of RAM? The answer is clearly "no" in that case, but mostly because Android devices are not targeted for that kind of work.
For comparison, BTW, my Win 7 x64 box that is nearly bare of applications (I only use it as a VM host) needs 1 GB of committed page space to sit there and do nothing. Android isn't doing so badly in comparison.
cheers
Click to expand...
Click to collapse
Hmmm
Well lets start with the last first, i run a heavily customized ( rt7 lite, wintoolkit, buclean ) windows 7 ( EE edition which i mastered ) on a asus g15w i7 8 gb geforce 470 , with all drivers in, on full aero , <>560mb mem usage for the system, can go down to 500 if you disable the nvidia startups and services but you lose the nvidia controll panel.
I totally take the point that memory usage in modern multi-core systems is friggin complex, obviously these memory stats are not supposed to be definitive in any way, but given all the tests are run on the same hardware with the same inbuilt prog they can be used as COMPARATIVE results, ie you can say rom x is more efficient than rom y given they do the same thing but with different memory results.
By definition any code abstraction away from 1's and zeros makes that code less efficient, an entire graphical os can fit into 1.8mb if written in x86 ASM, same code becomes <>20mb in C, 25mb in C++, 80mb+ in vm bytecode, the same pattern can be found in mem usage.
Any virtual machine no matter how clever ( and dalvik is bloody clever ) is a glorified interpreter, hence slower ( by a few factors ) than c/c++, which is itself slower by a few factors than ASM.
My opinion on caching is DONT, unless someone comes up with a really psychic piece of code that can for real predict the chaotic needs of the average human, all caching algorithms are just guessing, and do i trust the system to free up all that memory in time when something ( as you say ) calls up a massive heap or worst maloc's it direct, errrr no.
But thats just an opinion, am totally willing to recant if i see evidence and accurate benchmarks to the contrary ( and you seem to know your stuff, so if im way of the mark please enlighten me ! )

✪Tips to speed up your nexus7✪

Sometimes we feel that our nexus 7 us getting slower.Here are some tips to speed it up again!!
1 Free Up Some Space
Many people report that the Nexus 7 slows down as it fills up. When the 16GB Nexus 7 gets to about 3GB of storage space left, it begins to slow down.so freeing some space helps a lot.
2 Disable Currents Background Sync & Other Background Apps
Google Currents syncing is a notorious cause of lag on the Nexus 7. If your Nexus 7 is too slow or isn’t responding to touch events properly, open the Currents app, go into its Settings screen, and disable the Syncing option. This will prevent Google Currents from constantly downloading and writing data in the background.You may also want to disable background-syncing in other apps, or set them to sync infrequently — similar problems could be caused by other apps downloading and writing data in the background.
3 Delete Multiple User Accounts
If you have multiple user accounts set up on your Nexus 7, you may want to disable them. When you have multiple user accounts set up, apps on other user accounts are syncing data in the background — so if you have three user accounts, three different Gmail accounts will be syncing in the background at once. It’s no surprise that this can slow things down on the Nexus 7′s older hardware.
4 Android 4.2.2
If u ever upgraded to android 4.2.2 and felt there is some lag and found no other way 2 fix it dont hesitate to downgrade to 4.1.2 (I have done this as 4.1.2 feels a lot more faster than 4.2.2 for me.)
5-Run TRIM (LagFix or ForeverGone)
Due to a bug with the driver for the Nexus 7′s internal Samsung NAND storage, Android on the Nexus 7 was not properly issuing TRIM commands to clear unused sectors. This caused write speeds to slow down dramatically. This was fixed in Android 4.1.2, and Android should now properly be issuing TRIM commands to the internal storage.
However, this update does nothing to fix existing sectors that should have been TRIMMed in the past, but were not. To do this yourself, you can try the LagFix app from Google Play AND this will will fix the problem.Link-
https://play.google.com/store/apps/details?id=com.grilledmonkey.lagfix
6 My personal best recomendation
Use the AVG Memory & Cache Cleaner app. link- https://play.google.com/store/apps/details?id=com.avg.cleaner
After clearing the cache with this app my nexus 7 runs like new .Also try Advanced Task Killer, might help a bit.link- https://play.google.com/store/apps/details?id=com.rechild.advancedtaskkiller
Please press the thanks button :good: if this helped you!

6 - don't use too many widgets, they run in the background and can slow down your tablet too
Sent from XDA app

Task killers are pretty debatable. Android is designed in a way that means task killers can actually decrease battery life and slow the device down in some situations.
Sent from my Nexus 7 using XDA Premium HD app

The first few are common-sense solutions that demonstrably work on most devices.
The task manager and memory cache suggestions are snake oil and should be avoided. There is almost no evidence that demonstrates that any of these apps actually improve performance, and there's a lot that suggests they actually impede both performance and battery life. A task killer/memory cleaner sweeps through the system, looks for things not running in the foreground, and kills them. Sounds simple enough, right?
That is, until you realize that these programs can't prevent the apps they just killed from being triggered, and often cannot distinguish between benign apps that have legitimate background services and programs you don't want running. It then unloads them from memory (because free RAM is always good, right? Wrong), which generally results in I/O thrashing as the system tries to reload the killed applications and sees them killed again. And that ties up I/O operations, which have never been the Nexus 7's strong point.
And mind you, starting an activity is one of the most memory-intensive processes in Android, whereas keeping an app in a dormant state has significantly less impact on the system. Multitasking works better to boot, and battery life is better because the system doesn't have to waste resources regenerating resources over and over and over again.
As of this writing, the only real "performance boosting" apps I have seen are Lagfix and Greenify, because they go in at the system level (requiring root access) and actually make the right changes. Greenify temporarily "freezes" an app similar to the Disable option (or Titanium Backup) until it's in use, but unlike a task killer, it also shuts down any self-triggers an app might have to avoid thrashing. If you open the app, Greenify defrosts the app immediately for a minimal performance hit, then freezes it again after you haven't used it for a while.
Lagfix is an implementation of fstrim, which helps keep the internal memory running more smoothly. It's particularly useful on the Nexus 7 owing to the generally poor I/O performance of the internal NAND flash.

1) Install custom ROM
2) Install custom kernel
3) Overclock your CPU
4) Change CPU Governor to performance
5) Change Tegra 3 CPU Quiet Governor to Userspace
6) Setup ZRAM
7) ???
8) Profit

Username invalid said:
1) Install custom ROM
2) Install custom kernel
3) Overclock your CPU
4) Change CPU Governor to performance
5) Change Tegra 3 CPU Quiet Governor to Userspace
6) Setup ZRAM
7) ???
8) Profit
Click to expand...
Click to collapse
9) Come on XDA and complain about battery life.
Sent from my Nexus 7 using Tapatalk HD

veeman said:
9) Come on XDA and complain about battery life.
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
The more energy efficient ROM, kernel and undervolting would compensate for the higher clock speed voltage.

Username invalid said:
The more energy efficient ROM, kernel and undervolting would compensate for the higher clock speed voltage.
Click to expand...
Click to collapse
And the one step that users who would do 9) always mess up will invariably muck things up/they'll have bad sync settings and moot the whole process.

veeman said:
9) Come on XDA and complain about battery life.
Click to expand...
Click to collapse
Yep. Performance governor? Derp. This whole thread is derp.

Try many different ROMs with many different kernels, find the best match, and be happy with it
On another note, keep away from Gapps. They are a real issue, take about 50 mb on my phone, an the first thing I nuked after rooting. Beleive me, my HTC Sense forgot bein laggy after that. This implies to most devices. Every ROM that I have used, has been devoid of Gapps.

Use F2FS ported to nexus 7 by legolas
Sent from my Nexus 7 using Tapatalk

Another tip: apps may open faster with row io scheduler (prioritized read speed) in custom kernel.
Sent from my iPhone using Tapatalk

Amisuta said:
Another tip: apps may open faster with row io scheduler (prioritized read speed) in custom kernel.
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
which rom will you choose for better performance
omni or slimkat

nat510 said:
which rom will you choose for better performance
omni or slimkat
Click to expand...
Click to collapse
I haven't used omni or the normal slimkat before, but I've used the all-f2fs version, which works great.

nat510 said:
which rom will you choose for better performance
omni or slimkat
Click to expand...
Click to collapse
Omni worked much better for me. Also benchmarks are much much higher.
Sent from my Nexus 7 using Tapatalk

467) isn't there 45 000 000 other threads just like this?

Thank you :good:

Good tips.
I personally use ROW and performance governor with no overclocking and my tab runs super smooth.

Thanks.
Although Android 4.3 solved the issue with NAND Trimming.

T-Keith said:
Omni worked much better for me. Also benchmarks are much much higher.
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
Year, Omni is awesome

Frustrated!

I have xperia T with locked bootloader, so i can only try stock based roms. I was very satisfied with the phone, but not any more. I changed many roms,but with every rom, after about a month of usage phone starts to be be laggy, and slow. Especially the browser. It takes ages to load a page. Also typing seems to get laggy. After I flash different rom, everything gets to normal again. Does anyone have the same scenario, as. I am? Could something be done to speed up the phone?
Sent from my LT30p using Tapatalk 2

Maybe you have many apps?
Maybe you have mang apps that runs in the background?
Maybe your phone is broken?
You could install some tweaks such as V6 Supercharger.
You could clear cache once a while.
You could let your phone rest.
For me, I don't face this problem.
Sent from my LT25i using Tapatalk 2

I do have many apps. I clear cache once in a while, and phone feels better when i do that. But i never shut down or reset. I'll try to do that and see how it performs.
Thanks for your answer.
Sent from my LT30p using Tapatalk 2

I guess you don't have any special "issue" with your phone.
Every single phone lags - period. Sooner or later, and this or that moment, it lags. To be honest, I'm ok with that for quite some time. Every app is getting more hungry with every new version, and when you're installing and updating apps on daily pattern, it simply becomes too heavy for system resources to handle. For example, if you do a factory reset now on your T/TX, and if you're sticking with stock rom, there is 300MBs of updates right after first boot. I was shocked when I saw that my system memory jumped from 270MBs of usage after first boot, to 530MBs just after system apps updates...
Android lag tendencies are old story now. Google did not solve this yet, and project butter didn't make any notable changes regarding UI lag. Yet, I would't change it for iOS or WP for a whole world.

There for there will be trim support in android 4.3
It's like your windows based pc, after a while it will get slow. And so are android phones.

- Keep the least number of apps possible on the phone
- Remove widgets you don't really need
- Chose the smaller sized app with the humbler memory foot print, if there are alternatives
- Trim occasionally as what my predecessor mentioned, there are trim apps out there, like Lagfix
- Reboot once a day.
Sounds profane, I know.

i've tried many custom roms with LBL but never had this problem.
all i do is restart the phone once a week or two weeks..

mr_torture said:
I guess you don't have any special "issue" with your phone.
Every single phone lags - period. Sooner or later, and this or that moment, it lags. To be honest, I'm ok with that for quite some time. Every app is getting more hungry with every new version, and when you're installing and updating apps on daily pattern, it simply becomes too heavy for system resources to handle. For example, if you do a factory reset now on your T/TX, and if you're sticking with stock rom, there is 300MBs of updates right after first boot. I was shocked when I saw that my system memory jumped from 270MBs of usage after first boot, to 530MBs just after system apps updates...
Android lag tendencies are old story now. Google did not solve this yet, and project butter didn't make any notable changes regarding UI lag. Yet, I would't change it for iOS or WP for a whole world.
Click to expand...
Click to collapse
I was considering to chnage my phone, and go for S4, or HTC ONE, but because of those "Android lag tendencies", after a month of not reseting or cleaning the cache, they should lag olso. Am I right? I'm not familiar with WP or IOS. Do they have lag tendencies also ?

Andrija231 said:
I was considering to chnage my phone, and go for S4, or HTC ONE, but because of those "Android lag tendencies", after a month of not reseting or cleaning the cache, they should lag olso. Am I right? I'm not familiar with WP or IOS. Do they have lag tendencies also ?
Click to expand...
Click to collapse
Well, you will probably get a bit snappier performance with two mentioned phones, but believe me, if anybody tell you their phones are not lagging at all, like never ever, they lie. I played with S4, and I played with HTC One, and these also have glitches from time to time.
Regarding iOS and WP, I never personaly used any of those, but I played a lot with that phones, as my friends are having them. iOS is generally considered to have quite fluid interface, but that's because iOS is totally different system and is handling user interface with different priorities. And honestly, it is fluid. Especially since iPhone 4... But on the other side, it is such a limited system, that I never ever considered switching to it. WP is also quite fluid, but again, that giant-squares interface is very dull to me, and WP ecosystem is still far behind Android.
Point is, I'm not willing to change Android for some other weaker system, just for the sake of a snappier and more fluid interface...
But that's just me. Maybe somebody else is having different priorities.

Thanks for the honest answer. I can live with the reset from time to time. I also don't consider changing Android for iOS or Windows because Android has so many features over them. I hope in the future Google will manage to eliminate that lag.
Sent from my LT30p using Tapatalk 2

Andrija231 said:
I hope in the future Google will manage to eliminate that lag.
Click to expand...
Click to collapse
We all do... Practically, the only argument iOS and WP users are having, is that magic word "lag".
Other than that, Android is unbeatable in all other areas.

Big colourful icons, multi-function widgets, and many other eye candy functions use system resources without delivering a real value for the user. Windows has plump tiles, and the app drawer is just a simple list of apps. Just as examples. My wifes windows phone has 2/3 of the hardware power, but it worked fluid any time.
Change the icons to simple symbols, make a vertical scroll app drawer with tiny icons, remove widgets, use the app drawer to access apps. And so on. It will bring you leaps forward in terms of functionality.
Most will say that unused memory is wasted memory. I believe on the long run it's better apps have a proper exit button, and clear themselves from memory when done.

(INFO)ABOUT THE NEW ART FEATURE(KitKat)

I have open this thread for all(me included)user with no idea about ART,so here are some infos about it,what is ART,how does it work,pro+cons.
Maybe its helpfull for some peeps here.Source: Android Police
Link p1
Link p2
-------------
Part 1:
It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.
At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.
How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!
---------------------------------------------
Part 2 in next post.....

Part 2
---------
By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.
Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.
How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…
Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.
Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.
3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.
AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.
CF-Bench
For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.
Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.
The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.
Fast scrolling with dalvik: http://youtu.be/JGyktLPvORU
with ART: http://youtu.be/L9lpCssSdMc
To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.
Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.
Introducing ART from: source.android.com
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
------------------------------------------------------------
MANY GREEEETZ+STAY ADDICTED!!!!

Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app

velosa said:
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.

-CALIBAN666- said:
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
Click to expand...
Click to collapse
Thanks
Sent from my LG-E610 using XDA Premium 4 mobile app

thank you very much for your work about ART presentation ! very nice and perfect ! :good:
conclusion : don not use ART for the moment on CM11 ! ok ! wait more stability ...

i've downloaded gapps kk from cr3pt thread for cm 11, while i'm waiting for more stability i wanna ask you if they are art compatible.
Best presentation of ART!

When the gapps are odexed than yes.
STAY ADDICTED,GREEEETZ!!!

Anyone getting problem with use ART runtime??

My phone started lagging after I selected use ART in runtime...
I noticed that my Free RAM got increased not I m getting 450+ free RAM but phone processing got slow..

Even I tried ART Runtime and most of the Apps started crashing and the phone started to heat up, so switched it back to Dalvik.
I found some discussion going about this in Android Central forum here
I think for now Dalvik is the better option , since ART is not supported yet in 4.4.4.
Android L has it though!

I noticed that too. A few apps started crashing after i changed.
Besides that, everytime i reboot my phone the message that my android is being updated and the apps are being optimized.

I used Art on Nexus5, worked smoothly, for some reason my Moto G 1st Gen and Moto G 2nd Gen don't work half as smoothly as the Nexus 5. Anyway lollipop will be out soon, so no worries

ART was quite OK in Moto 2013, but due lack of disk space, I used Dalvik. In Moto 2014 ART is very slow, apps crashes etc.

Not sure why you all are having problems. I've been running ART since receiving my phone 3 weeks ago and haven't had a single app crash, nor do I see any lag at all.

+ Every time my phone boots...
I see a message...
" Android is upgrading.... Optimizing apps.."...
So switched back to Dalvik...
I think ART having problem with kitkat..

My phone stopped upgrading on each boot, this might be the solution:
http://forum.xda-developers.com/showpost.php?p=56506819&postcount=27

temuulenchoi said:
My phone stopped upgrading on each boot, this might be the solution:
http://forum.xda-developers.com/showpost.php?p=56506819&postcount=27
Click to expand...
Click to collapse
I'm not using ART anymore because its not yet compatible with Xposed, but it seemed to work well when I used to use it.
It stopped doing the "upgrading apps" thing at startup after about 5 reboots.

This may help you...
cyb3rillusion said:
My phone started lagging after I selected use ART in runtime...
I noticed that my Free RAM got increased not I m getting 450+ free RAM but phone processing got slow..
Click to expand...
Click to collapse
Dalvik is based on JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.
ART compiles the intermediate language, Dalvik bytecode, into a system-dependent binary. The whole code of the app will be pre-compiled during install (once), thus removing the lag that we see when we open an app on our device. With no need for JIT compilation, the code should execute much faster.
ART is an ongoing project, considered too unstable to be introduced as a standard runtime in 4.4.4 Kitkat
"So before you switching the Runtime from Dalvik to ART you have to reset entire mobile or clear the Dalvik cache via CWM and then install the apps you want to run.". Because the cache memory created by Dalvik runtime won't allow the ART to run Lagfree.