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!!!
Related
I was just wondering, why do we try to optimize stock .apks? If HTC or T-Mobile released them, I doubt they would purposely bloat them up or anything to make them even the slightest bit slower. What if our "optimizing" instead has zero or in fact adverse side effects? My point is if it could be further optimized, then HTC would do it. (This is just out of curiosity)
Well, to be brutally honest, I highly doubt T-mo, HTC, etc. actually goes through their newly made apk, to look for any and all optimizations right off the bat, their most likely far too busy, and odds are, they could care less, as long as it fits in the first place.
As far as adverse effects, I for one haven't noticed anything slow/unacceptable about any apps, I've ever used
And most of the optimizations are so that the apk will fit in the actual ROM release ( guessing here, I'm not really a 'developer' ;P ) givin' that the rom contains many apps/etc.
Although with most apps2sd stuff going on now, I don't see the point, but it's still valid
(Look at in the eyes of a user, if a file is 20mb, and takes 20secs to dl, or 10mb and takes 10secs to dl, for the exact same thing, which would you pick?)
Hope I cleared up some stuff, or at least brought up some more/different questions xD
The real reason? So "devs" can type "ZOMG! Optimized all apks!!!" on their rom descriptions. The supposed "optimization" boils down to two steps: using optipng or roptipng; a tool that does some agressive, yet still lossless, compression passes to png formated images and reduces their sizes by certain amounts (depending on previous compression, up to ~60%), and then running zipalign; a tool from the android sdk that aligns the zip/apk to dalvik memory so that loading and execution become a tiny bit faster.
coolbho3000 made a windows bat script that does all that automatically plus a third step, compressing the apk/zip to anorexic levels with an agressive, mx5 zip compression. This usually cuts down the size of the /system/app folder a reported 10%.
Why do it? Size. It's the ONLY advantage. Most people seem to forget that compression requires decompression at runtime, and the more aggresive the compression algorithm used, the more cpu cycles and memory it requires to decompress, in fact, making your whole experience slower and less enjoyable. About the only thing that's beneficial in the whole "optimization" is running zipaling, but then whatever gain is lost by the heavy compression everywhere.
Don't get me wrong, shrinking everything has it's advantages, for example, I was able to whip a WHOLE Hero build into the space of the death spl's /system partition because of compression, but actual usage was frustrating because the system would so often run out of memory (or, if used with 64 MB compcache, be just too slow). I actually created another build (just a test) with no compression anywhere, just zipalign, and it was so enjoyably fast, but having only 20 MB left in /data after a fresh install is no fun...
So there you go! roptipng>7za>zipalign make all masters of "optimization" (we have only about 1 person here in the forum who's actually gone on the nitty-gritty of editing baksmali dumps and actually trying to make the damn thing run faster/properly).
If you have ever had T-Mobile motorola Z3, then you kow that T-Mobile DOES slow down the os on phones they can, or at least some of their proprietary apps do, like my faves, cause thats what got me into modding a lot, (and comp programmin ) i just wanted a faster z3 lol.
Way above my skill-set. But when you near 45, I think you tend to get that way.
Seriously, if this could be used on our SGS, can it make for a smoother scrolling experience?
I'll try to merge this patch to the currently used kernel source and see what happens.
Had the low latency patch applied and running for a while since.
Need some changes to get it in Android kernel, but nothing drastic, and judging by the code in tty_io.c, groups are created as per tty, would not work on Android, needs manual grouping, and have not seen any improvements though.
Not worth the trouble.
IMHO, scheduler isn't really the issue here, unless you're running a few CPU intensive programs in background, to which isn't the Android's way of doing things, you would be sharing the CPU intensive foreground app resource with background app, that has neg effect, things get slower instead.
"Low latency, the more responsive UI gets." statement maybe true but UI's 'responsiveness' has more than just a low-latency kernel to it.
I'm looking for a fast ROM, battery is not so important, with JIT compiling that's stable....anything anyone can suggest?
Currently using Super AOSP (using it now, some apps don't run, otherwise stable). Radio=27.08, Haykuro SPL....
Most of the loads I've tried are either buggy or I can't load them for one reason or another (A lot of roms fail during load - is that my phone?)
I don't need a lot of bells and whistles, I do EMAIL, I do Web Surf and play an occasional game, but I don't really need lots of other things, I would gladly give up visuals for some increased speed - currently 2.6 MFLOPS (Linpack free).
Thanks.
best I can do for now....4 MFLOPS on G1
I think I found the best for me right now, Ginger Yoshi gives me 4 MFLOPS, which is not as good as I wanted, but I've set my sites lower.
It is very smooth - it does not feel refined, don't need it, everything works.
I can recommend SuperAosp, it is very refined, everything looks finished. It is not nearly as fast as Ginger Yoshi, but it is pretty and stable.
I did try several other loads, and I'm thankful that there are developers out ther, so I won't mention names, but at least one of these loads gets a lot of press on here and on my phone, I'd call it buggy.
Super Aosp and Ginger Yoshi are both stable.
It sounds funny, but try turning off JIT. It seems to make roms a lot more stable; I'd guess the G1 just isn't up to snuff for JIT. It makes benchmarks lower, but in practice it works much smoother.
Thanks for the reply!
I am turning off JIT...Then let the phone sit for a couple of mins to finish any housekeeping.
Ginger-Yoshi
JIT = Yes, Speed = 4.1 MFLOPS
JIT = No, Speed = 2.45 MFLOPS
Odd note, one of my non JIT runs ran at 1.6 MFLOPS, I didn't count it since it was so far out, not sure if there was housekeeping going on or what.
Second note, disabling JIT did make installations more stable - I was unable to install and sometimes download a specific application, disabling JIT allowed it to D/L and install.
Super-AOSP
JIT = Yes, Speed = 2.6 MFLOPS
1.6 Google - Rooted, speed to 528 MHz
2.4 MFLOPS
1.6 Google stock
1.4 MFLOPS
I've never run 2.0 or 2.1 so I don't know how they stack up, they do not have JIT, so maybe they are more efficient.
What I really wanted was a 1.6 OS with everything moved to the SD card AND JIT and CPU set to 528 MHz otherwise stock, I expect that is about as fast as this phone can go.
My limited experience:
I can't speak for anyone else but Super-Aosp and Ginger-Yoshi are very stable.
I tried several others that were not so stable, though they have lots of loyal fans, maybe their phones are better than mine.
I agree that we should be able to build a tight system without JIT that is faster, efficiency is the key.
A buddy of mine, has a very fast Android LG Optimus phone - it fly's he can run all sorts of animation, applications etc. and it doesn't seem to affect the speed of the phone...He runs 9 MFLOPS which is WAY above what everyone else with the same phone has...he told me that he isn't modifying the subroutines/calls, he's sort of linking scripts to make things run more efficiently. He's a physicist not a programmer.
He just constantly tinkers with it though - some bits are buggy, it's just a hobby for him, he has development tools right on the phone
My current Ginger-Yoshi runs just over 4 MFLOPS, which is less than I wanted but all I can find so far.
JIT is NOT a good match for this hardware, for the simple reason that JIT consumes more RAM.
What you have is a piece of hardware that is SEVERELY RAM LIMITED. Eating up even more of it causes necessary components to be booted out of memory, which ends up causing long periods of WAITING while those components RELOAD. It can also lead to instability, since the available memory will IN MANY CASES, be insufficient for loading even a single program into memory.
Counting FLOPS is a very poor measure of overall system performance. I would bet you that in terms of overall usability and wasted user time waiting, your phone will actually be FASTER with JIT DISABLED.
Ignore FLOPS. It is irrelevant.
dhkr234 said:
Ignore FLOPS. It is irrelevant.
Click to expand...
Click to collapse
I appreciate your argument and I 100% agree that the phone is ram limited, can you suggest another build that does not use JIT?
My current Ginger-Yoshi is faster and smoother than any 1.6 I've run (I have not run Super D, that was going to be my next target if G-Y was buggy).
That goes back to my original reason for this post...fast enough to play angry birds or whatever I'm doing.
You say to ignore FLOPS, that is the fairest test That I know for different phones,<Millions of> Floating Point Operations Per Second..that bypasses graphics co-processors and gets down the the meat of what's going on inside.
If you can suggest a ROM that runs better than G-Y I am very willing to try it, but right now the very best ROM I've tried is G-Y (not perfect but better than Anything I've run on this phone).
GolfnWrx said:
I appreciate your argument and I 100% agree that the phone is ram limited, can you suggest another build that does not use JIT?
Click to expand...
Click to collapse
I would expect that you can switch on/off JIT in your settings, so you can try if for you JIT helps or not. G-Y doesn't provide this? (Sorry for the question, but I've never tried it ...)
If there is no option within the ROM, you could add
Code:
dalvik.vm.execution-mode=int:fast
to you /system/build.prop to disable JIT, or
Code:
dalvik.vm.execution-mode=int:jit
to enable JIT.
Sent from my Gingerbread on Dream using XDA App
haha, sorry I guess I was not clear
yes, i can enable/disable JIT....what I was asking for though was a stable build that is faster than 2.5 MFLOPS.
There were some people last year that found a way to script one of the roms to be more efficient....IIRC they were able to get up to 3.7 MFLOPS....but I don't see them around any more....no JIT it was a rebuild of 1.6 I think..maybe 2.1, I just don't recall.
That might be the best way to go, or they might have hit an error...I didn't keep up with it.
Thanks for the reply though
So you want a script to spoof Linpack?
Sent from my Gingerbread on Dream using XDA App
dhkr234 said:
JIT is NOT a good match for this hardware, for the simple reason that JIT consumes more RAM.
Click to expand...
Click to collapse
Overall my opinion on JIT (vs. android version)
1.6 - caused some apps problems otherwise seemed the same w/ or w/o jit.. maybe more ram and slower
2.1 - extra ram caused problems with services and slow load times.. improvement at run time minimal.
2.2 - improvement at runtime noticeable but still high memory use and very slow load times
2.3 - incrreased memory use and loadtimes; but more minimal than earlier versions; with screen andimations off/fast perfomance may be acceptibal to many given the better performance of the browser and other higher processing tasks. [at least in a light weight rom]
(Of course this is my opinion durring use .. not a linpack score)
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 ! )
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.