The ASUS ZenFone 2 Review
by Brandon Chester on May 26, 2015 8:00 AM ESTNAND Performance
While it's not disclosed by manufacturers, the speed of NAND on a smartphone is a very important aspect of overall smartphone performance. It has an impact on how long cameras can do burst capture, and how well the phone performs when apps are running both in the foreground and the background. To evaluate the NAND performance of the ZenFone 2 I've run it through both of our internal storage benchmarks. Because our iOS benchmark only supports a single IO thread, we'll be using our older storage benchmark alongside the newer Androbench 4.0 test for the foreseeable future.
In our original single threaded storage benchmark the ZenFone 2 is decidedly average in its performance. In every case it's either slightly above or below the median result on our charts. It's important to keep in mind that this test puts devices like the Galaxy S6 with its UFS storage at a disadvantage, as its NAND can make use of several IO threads due to the use of a command queue.
In our newer AndroBench 4.0 storage test we see that the ZenFone 2 ends up falling farther behind the other devices that we've run through the test. In the sequential read test it's not the slowest device, but that's only due to the Nexus 6 being extremely far behind every other device as a result of Google's full disk encryption. In the sequential write and random read tests it's comes behind the HTC One (M9), although to a very small degree in the latter test. Random writes are where it really stumbles, with a speed that's less than half of the next slowest device.
I'm not sure whether I can attribute it to the enormous amount of RAM that the 4GB version of the ZenFone 2 can use as a cache, but I never noticed any issues with performance as a result of IO operations being run either by the app I was using or by another application in the background. Even when updating applications, performance remained consistent.
Facebook
Twitter
RSS
147 Comments
View All Comments
der - Tuesday, May 26, 2015 - link
Sweet review mates. Y'all the best!Daniel Egger - Tuesday, May 26, 2015 - link
Two things:1) The x86 problems are very real; about any serious Android application contains native code for performance reasons, the rest are very non-demanding gimmicks or simple games. There're still plenty of application which do not even attempt to run on x86 which can be easily seen by e.g. checking the F-Droid repository with the app. And of those which do run quite a few simply don't work correctly; I've found quite a few of those in the Humble Bundles. My suspicion is that the developers do compile them for x86 but do not really test them on that platform...
2) Those Silvermont cores do have decent performance but I've yet to see a single implementation where battery life doesn't suck. One discovery I've made is that those devices are very reluctant to go into deep sleep, even with some tweaking they'll usually stay on the lowest possible frequency most of the time. Could be that the software is not quite ready to properly handle those Intel cores or they simply suck...
MikhailT - Tuesday, May 26, 2015 - link
Both are software issues. Google doesn't have any incentives to stick with ARM only, they'd want to work with Intel to fix these issues.At my work, we had an issue where our app would crash on Intel devices, it took us a few weeks to figure out that it was a low-level bug in Android. We filed a bug report but no news if Google or Intel will fix it. We managed to work around it but it was difficult and took a lot of time.
The latest rumors is that Android M is supposed to work on the battery issues. Hopefully, that includes optimization for Intel SoCs.
kpb321 - Tuesday, May 26, 2015 - link
I was surprised that the review seemed to skip this entirely. It is certainly an issue when dealing with x86 android phones. Theoretically any app that doesn't include NDK "should" work fine on x86. My experience with Android phones/tablets was that I don't ever recall installing a single app that had NDK in the permissions list so it didn't seem like it was very common to me. On the other hand I've never actually had an intel tablet to actually see how good or bad it was.Brandon Chester - Tuesday, May 26, 2015 - link
I also reviewed the Venue 8, and like I said in both this review and that review, I have never found a single app that doesn't work because the SoC is x86. A lot of people like to say that there are lots of apps that have issues, but they never seem to name any so there's no way for me to actually confirm that. If people do know of some problematic apps please let me know via email or Twitter so I can take a look.Muyoso - Tuesday, May 26, 2015 - link
An app called Photo direct that I use for work crashes instantly when launched.rocketbuddha - Wednesday, May 27, 2015 - link
I bought a Dell Venue 8 with KitKathttp://www.bestbuy.com/site/dell-venue-8-8-intel-a...
and found that it was the POS.
Dunno if it was 1GB RAM that came with it, but it was hanging even while opening tabs in chrome/stock browser.
With Lollipop, Google officially has both a ARM as well as x86 version it tests and releases. Pre-lollipop it was Intel who customized Android to work with its Atom processors.
Maleficum - Saturday, May 30, 2015 - link
Brandon, you'd be really surprised to know that most apps in the top charts are using NDK.Google claims that 85% apps are written in Java. I'm not saying it's a lie, but it is far from realistic since most apps in the top charts - apps most people use most of their time - are NDK based.
Even more surprising would be the fact that roughly half of these apps contain ARM binaries only, thus forced to run via binary translation that results in a performance reduction of roughly 70% while the power consupmtion doubles.
In that sense, your article is misleading IMHO, simply repeating Google's claims.
http://www.theregister.co.uk/2014/05/02/arm_test_r...
I think it's clear why so many apps are NDK based: Java isn't simply the right language for computationally intensive apps, and primitive apps written in Java cannot make it into the top charts.
And app developers aren't interested much in supporting x86 natively considering the tiny market share. No one can blame them for neglecting x86.
That's the reason why I'd never buy nor recommend x86 Android phones, and Intel having difficulties getting foothold in mobile segment.
I think it would be worth an investigation and probably a separate article.
Thunderc8 - Saturday, May 30, 2015 - link
I have installed all known apps and then some and all working perfect and super fast. If what you say is true then Intel CPU is a beast since it looses so much performance and at the same time is so Damn fast.coolied - Wednesday, May 27, 2015 - link
NDK wouldn't be in the permissions list, it simply means the app was coded in C++ and not JAVA. Unfortunately, most apps you would WANT to run and run WELL are written in C++ aka most 3D games.