Linked by Thom Holwerda on Thu 19th Jun 2014 09:58 UTC

Ever since we first saw ART appear alongside the release of Android 4.4 KitKat, we all knew that it would eventually replace the aging and relatively inefficient Dalvik runtime compiler. Well folks, the time is now upon us, as commits made late last night to the AOSP master branch show Dalvik getting the axe and ART being set as the default.

Should deliver some decent performance improvements. I tried switching to ART months ago but ran into problems with some applications not working properly. Has the situation improved? Are any of you using ART?

Permalink for comment 590943
To read all comments associated with this story, please click here.
by said1 on Thu 19th Jun 2014 15:59 UTC
Member since:

There's no tecnical reasons why ART should be faster than Dalvik, other than more optimization work have been done by Google on ART rather than Dalvik. By its technology, ART should be faster during the first startup and the first execution of an application (the code compiled by Dalvik is then cached too). However the better startup time usually give to users the perception of more speed.
All this obviously applies only on Java code, applications compiled with NDK will not be affected.
The main drawback is that all the Java applications will occupy roughly twice the space: the bytecode and the compiled code.
Another possible drawback is that the code will not be profiled during runtime, losing the possibility to be further optimized: this is the reason why HotSpot is faster than gcj or jet on longer executions that compensate the time spent into compilation and optimization.


Early ART benchmarks, including battery usage:

Disadvantages with native or almost native architectures, like Apple, Jolla, Tizen, etc., surely will not be eliminated at all. These were obviously clear from the beginning of Android development: they preferred to have better sandboxes and CPU neutrality.

Reply Score: 1