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 ! )

Dedicated Runtime Thread (ART vs Dalvik)

Okay guys,
with the introduction of 4.4 kitkat, Google decided to include ART as an optional second runtime that can be enabled through developer options. Naturally when promised faster app launch times, people will turn it on. ART is not stable however and so problems will be occur. For this reason, in hopes to prevent kernel developers, rom developers, and android developers from having their thread hijacked, I am making a thread dedicated to runtimes here. DO NOT POST ABOUT THIS TO DEVELOPERS ON THEIR THREADS, bugs when you are running ART are not their fault.
What is Dalvik?
Dalvik is the process virtual machine (VM) in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed. Dalvik is open-source software.
Dalvik is named after an Icelandic city.
(source)
Okay so what is ART?
ART is a project Google has been working on for reportedly for 2 years. The goal of ART was to produce a faster runtime that wouldn't suffer from the problems Dalvik suffers. Android Kit Kat 4.4 is the first operating system with ART included in developers options although it is unclear just how recent this version is.
ART stands for Android RunTime
(source)
Great, Whats the Difference Then?
The main difference between ART and Dalvik is when they compile app code. Dalvik operates under a JIT (Just In Time) compilation method which means that when developers make their apps, they partially compile their code into bytecode which is interpreted by the java virtual machine. Dalvik converts bytecode to machinecode as the app runs to increase performance (bytecode execution is slower than machinecode execution). ART differs from Dalvik by performing this compilation of bytecode to machine code at installation of the app and saves this to the phones storage (not ram).
(source)
So Why Use ART?
Using ART instead of Dalvik allows the system to use much less resources during runtime. When apps are running, interpretation of bytecode is not ongoing, this can reduce CPU load and RAM usage. The resulting effect is faster app startup times (reportedly almost twice as fast) and better in app performance.
It should be noted that performance boosts will only really improve for the java components of apps. Apps like games which rely on the NDK or other languages will receive more incremental experience boosts.
(source)
Why Shouldn't I Use ART
Well first and foremost, Google's documentation of ART suggests not using ART because it can cause app instabilities and an unstable android implementation all together. It is still largely in development and it is unknown just how recent the version included in the current kit kat build is. Google is introducing it to the development community but really doesn't intend users to use it as a daily runtime.
Also since ART precompiles and saves that precompiled code upon installation of apps, it takes up more storage. The increase is about 10-20% of the code in the application. Remember the majority of apps usually comprises media files such as images, videos, sounds... so those components will be unaffected. For example, the Google+ apk is about 28Mb yet the code is only comprise of 7Mb. The increase in storage size is nominal, but worth noting.
Also the first start up after enabling ART can take up to 10 minutes due to this compilation occurring. Installation of apps will also take slightly longer but with hardware on the Nexus 5 you are unlikely to even notice.
ART also can cause issues with app backup and restoration.
(source) (source)
Custom Roms and ART
As developers start building Kit Kat roms from source they will have to decide if they would like to include ART in their builds. Google has created a flag to include ART in addition to Dalvik. This is a simple implementation, but if threads keep getting hijacked by discussions of ART and bugs, I wouldn't be surprised if developers choose to exclude ART from their builds.
ART also cannot function with deodexed apps. The odex files are necessary for bytecode to machine code compilation. Flashing a deodexed ROM or gaps with ART enabled will produce force closes and crashes to the point the UI won't be functional.
Also initial setup between Roms will take longer with ART since performing a factory reset as well as clearing caches will clear the stored precompiled code that ART saves. Dalvik will always be enabled at start up, so switching to ART will require a reboot and a wait for set up.
(source)
In my synopsis of ART and Dalvik I may have made a mistake or two or not explained something properly. If you spot a mistake or would like clarification, simply post and I will modify the OP.
Please, please, please send people to this thread if they are asking about runtimes in a developers thread. Having had my kernel thread hijacked by unrelated issues that are outside of my control, I understand the pain.

ART breaks Titanium Backup, just fyi
Sent from my Nexus 5 using Tapatalk

And quadrant and whatsapp

afazel said:
ART breaks Titanium Backup, just fyi
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
added to OP

I will not be posting a complete list of apps broken by ART, it would take way too much time and this is likely to change as the developers get to update their code to be optimized on 4.4. You are welcome to post any issues, but its pretty much ART can break a lot of apps.

I find app compatibility remarkably high. I have over 60 apps installed and the only ones that aren't working is titanium backup and greenify.
Everything else works even games like asphalt 8 and pvz2.

dwang said:
I find app compatibility remarkably high. I have over 60 apps installed and the only ones that aren't working is titanium backup and greenify.
Everything else works even games like asphalt 8 and pvz2.
Click to expand...
Click to collapse
Games generally are not coded in Java (usually NDK or something else) and so they will be effected much less by ART than other apps.

I thought that the play store felt noticeably faster when using ART when I was installing a bunch of apps last night.
Titanium backup and whatsapp instability are huge deal breakers for me, unfortunately.
Sent from my Nexus 5 using XDA Premium 4 mobile app

dwang said:
I find app compatibility remarkably high. I have over 60 apps installed and the only ones that aren't working is titanium backup and greenify.
Everything else works even games like asphalt 8 and pvz2.
Click to expand...
Click to collapse
greenify seems to be working fine for me with ART. What problems are you experiencing?

agalvin13 said:
greenify seems to be working fine for me with ART. What problems are you experiencing?
Click to expand...
Click to collapse
Perhaps a reinstall on ART would fix the problem?

Hi,
I know this may sound really stupid but.. can you guys write down some of your most used Apps that are written in Java? Do you notice any performance improvement?
Also, does ART affect overall android experience (original apps, launcher).
I am no developer and I don't know much about computer languages (so please don't throw rocks at me for those questions) but I like to tweak my phone to see what seems to be the best for my phone.

Does ART affect battery life?
Sent from my Nexus 5 using Tapatalk

MrBelter said:
And quadrant and whatsapp
Click to expand...
Click to collapse
Quadrant is working just fine for me.

busab said:
Does ART affect battery life?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
It theoretically will and could. I haven't noticed a markable increase in battery life so far though. One would have to perform some test but scrolling and apps loading seems more fluid imo. I am leaving it on.

busab said:
Does ART affect battery life?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Not sure, tomorrow I'll see and report back.
It's not like the new Holy Grail to me, performance wise...

busab said:
Does ART affect battery life?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Theoretically, yes since it attempts to decrease cpu load and ram usage at runtime, it should theoretically give you some better battery life. But battery life is hard to gauge, so don't expect any definitive results on that anytime soon.

miHah said:
I know this may sound really stupid but.. can you guys write down some of your most used Apps that are written in Java? Do you notice any performance improvement?
Also, does ART affect overall android experience (original apps, launcher).
I am no developer and I don't know much about computer languages (so please don't throw rocks at me for those questions) but I like to tweak my phone to see what seems to be the best for my phone.
Click to expand...
Click to collapse
Pretty much all apps that are regular run of the mill apps will be coded in Java. It is just intensive programs like games are generally coded using the NDK, but all other apps in large will be in java (the vast majority).
When you say original apps, I assume you mean system apps like the GE Launcher, or settings app. These are all coded in java so yes they will get improvements too.
EDIT: if you want what is best for your phone, stick with dalvic, it's more stable.

Something I noticed with the Nexus 4 (Dalvik, obviously) is that if you have a lot of apps (10+ maybe?) open, the recent apps will take a slight delay to show up. It isn't lag, but it even appears with the Nexus 5. If you switch to ART, the recent apps will show up immediately, no matter what. I'd say that alone would be worth it to switch to ART, it makes everyday use feel notably smoother.

aletto said:
Something I noticed with the Nexus 4 (Dalvik, obviously) is that if you have a lot of apps (10+ maybe?) open, the recent apps will take a slight delay to show up. It isn't lag, but it even appears with the Nexus 5. If you switch to ART, the recent apps will show up immediately, no matter what. I'd say that alone would be worth it to switch to ART, it makes everyday use feel notably smoother.
Click to expand...
Click to collapse
I agree - the bad part is that it breaks tibu and whatsapp. Why can't devs be a bit more on their toes when an update comes ?

Been running ART for a full day now, and aside from TB, I've had no issues. Greenify works fine, and I don't use Whatsap, so hopefully by the time custom ROMs that support ART come out, TB will be updated to fix this issue. If not, oh well. I'll stick with it for now seeing as how much better some notoriously slow and crappy apps are running. Maybe it's just a placebo, but I've never seen the Facebook app load so quick and scroll so smoothly as it does now.

[Q] 4.4.4 Optimized Dalvik on Z1

This is not my work but found it on the Xperia Z forums
I have installed it on my STOCK 4.4.4 (108) ROM and I wouldn't be able to tell the difference, yet
What is the differences of Dalvik, Optimized Dalvik and ART
This optimized dalvik I believe speeds up benchmarks (not that we should care about that) but I want to know the true value and what it truly does
of course, set backs if any
Flash at own risk

Dalvik - just install the app/game but rest of the codes that are necessary to work get build the moment you open app/game (sometimes you need to wait a bit)
ART -on the other hand install app/game and rest of the codes on phone while installing and that means less CPU usage, lower battery usage and overall speed increase but demand more memory on phone/SD card to install.
Optimization Dalvik, I didn't hear about that.
Ps. ART is disabled by Sony and Samsung, you can't make it work now.
But android L will work on art natively.
Sent from my C6903 using XDA Free mobile app

ART, F2FS, Lollipop, MM - Are any of these good boosts/alternatives to Kit Kat?

I'm running jcsullins CM11 (20151116), Kernel 3.0.101 (also TWRP 2.7.1.0)
Then using Kernel Tuner I pushed the max CPU to 1782Mhz
I don't use the tablet for many resource hungry apps (Spotify, Reddit, KLWP) but it's prone to being a bit laggy. I'm just wondering (within the bounds of possibility of a 5 year old tablet) if there's anything else I can do to speed it up a bit.
Seems to me like ART on CM11 isn't much more than a proof of concept. I don't really understand filesystems that well to be honest, and I'm reading conflicting posts about whether L or MM based roms are better or not (Evervolv or jcsullins 12.1)

Ok, so with almost 150 thread views in 3 days and no replies, I've taken it upon myself to try these to see how it goes. I'll continue to edit this post with what I find if anyone is interested.
I'm only interested in my perception, not benchmarks. Especially when benchmarks can be differently optimised across OSes and I intend to bounce around a bit.
Dalvik/Art
First thing I did was nandroid and titanium backups, then enabled ART in Dev options. First boot took a couple thousand years to get past the boot animation and Optimising Apps screens (expected) and then the tablet was slow as molasses (somewhat expected). I let the tablet settle down, then rebooted it. Next I methodically opened each app and played around with some basic functions. I then rebooted and repeated the process.
What I've noticed:
The initial boot, running each app etc is a bit of a painful process, but it's worth it. Everything starts up a little faster. Still a bit of lag, but not bad. No app crashes/incompatibility that I've come across so far.
F2FS
Basically this test failed. Flashed TWRP 3.0.0, changed the filesystems and rebooted. Got past the initial setup but no apps would install or update (even play store). Rebooting is like initial boot every time, going through adding wifi, google account etc. Something somewhere isn't writing to this new FS. Good enough reason to wipe it and move on to MM

For F2FS I think you need to use a rom that supports it, such has evervolv.
I tried out cm12.1 and evervolv(mm 6.0).
cm12.1 play store would always crash for me, tried it twice wiping everything. (I did not try Jcsullins version)
evervolv is very nice, the layout of android 6.0 (and 5.x) looks much better then android 4.x (personal opinion). I had zero problems with things not working/crashing. However if your looking for responsiveness, I think your best bet is kitkat with art and overclocking the cpu to 1.78ghz. Performance and battery usage is better in cm11 then anything else I tried. (my opinion).
For cm I use the milaq builds as they are more recent and incorporate security fixes.

Apps delayed opening after wiping Dalvik/Art Cache!

I wiped Dalvik/Art Cache from twrp being curious on my device. The boot took 30 seconds extra but that was okay. But now apps are delayed starting like white screen at first then starting with 1second delay!? Can anyone tell reason and a fix and the theory behind this?

You might know that Android runs apps in a "virtual machine", called Dalvik / ART. In computer science, a general principle to get things to run faster is to pre-compute them, or to re-organize them to make them run faster. It's exactly what's done with the Dalvik / ART cache - bits of program that are used and run more often are translated and organized into a language that your device can run faster and does not have to "re-interpret" each time the app is launched. This process takes some extra time and storage space, so that's why not all apps are necessarily optimized this way, but it's rather the Android OS that identifies recurrent code paths and tries its best to optimize them, based on complex heuristics.
The reason for which people sometimes suggest cleaning this cache is that you always want to make sure that the "optimized" code matches the actual apps and services you're running. If the optimized code doesn't match anymore, you might end up with some severe inconsistencies or some unpredictable bugs.
Over time, as you use your apps, their performance should get optimized again, based on your usage patterns, as the Dalvik / ART cache slowly gets filled up again.