As alluded to in our Nexus 6 review, our normal storage performance benchmark was no longer giving valid results as of Android 5.0. While Androbench was not a perfect benchmark by any stretch of the imagination, it was a reasonably accurate test of basic storage performance. However, with the Nexus 5 on Android’s developer preview, we saw anywhere between 2-10x improvement to Androbench’s storage performance results with no real basis in reality. It seems that this is because the way that the benchmark was written relied upon another function for timing, which has changed with Android 5.0.

While we haven’t talked too much about AndEBench, it has a fully functional storage test that we can compare to our Androbench results. While we’re unsure of the 256K sequential and random read results, it seems that the results are equivalent to Androbench on Android 4.4 when a 1.7x scaling factor is applied. However, AndEBench results should be trustworthy as we saw no difference in results when updating devices from 4.4 to 5.0. In addition, the benchmark itself uses low level operations that shouldn’t be affected by updates to Android.

Androbench Results - Valid vs. Faulty
  Nexus 5 Androbench Results on 4.4 KitKat Nexus 5 Androbench Results on 5.0 Lollipop
Random Read 10.06 MB/s 27.70 MB/s
Random Write 0.75 MB/s 13.09 MB/s
Sequential Read 76.29 MB/s 182.78 MB/s
Sequential Write 15.00 MB/s 47.10 MB/s

As you can see, the results show a degree of improvement that is well beyond what could realistically be accomplished with any sort of software optimizations. The results for the random write test are the most notable, with a result that suggests the performance is over 17x faster on Android Lollipop, which could not be the case. This required further investigation, and  it's one of the reasons why we were hesitant to post any storage benchmarks in the Nexus 6 review.

The other factor affecting the results of the benchmarks on the Nexus 6 specifically is Android Lollipop's Full Disk Encryption (FDE). Android has actually had this ability since Android 3.0 Honeycomb, but Lollipop is the first time it's being enabled by default on new devices. When FDE is enabled, all writes to disk have the information encrypted before it's committed, and all reads have the information decrypted before they're returned to the process. The key to decrypt is protected by the lockscreen password, which means that the data should be safe from anyone who takes possession of your device. However, unlike SSDs, which often have native encryption, eMMC has no such standard. In addition, most SoCs don't have the type of fixed-function blocks necessary to enable FDE with little to no performance penalty.

As a result, we've observed significant performance penalties caused by the use of FDE on the Nexus 6. Motorola was kind enough to reach out and provide a build with FDE disabled so we could compare performance, and we've put the results in the graphs below. For reference, the Nexus 5 (Lollipop) numbers are run using Andebench, while the original values are read out from Androbench on Android 4.4. The Nexus 5 is also running without FDE enabled, as it will not enable itself by default when updating to Lollipop via an OTA update.

Internal NAND - Random Read

Internal NAND - Random Write

Internal NAND - Sequential Read

As you can see, there's a very significant performance penalty that comes with enabling FDE, with a 62.9% drop in random read performance, a 50.5% drop in random write performance, and a staggering 80.7% drop in sequential read performance. This has serious negative implications for device performance in any situation where applications are reading or writing to disk. Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties.

When the Nexus 6 review was published, I commented that there were performance issues that weren't present on the Nexus 5 running Android Lollipop. Many users commented that the FDE may have been to blame. Like I mentioned earlier, Motorola provided us with a build of Android with FDE disabled. Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display. 

To me, the move to enable FDE by default in Lollipop seems like a reactionary move to combat the perception that Android is insecure or more prone to attack than iOS, even if that perception may not actually be accurate. While it's always good to improve the security of your platform, the current solution results in an unacceptable hit to performance. I hope Google will either reconsider their decision to enable FDE by default, or implement it in a way that doesn't have as significant of an impact on performance.

POST A COMMENT

93 Comments

View All Comments

  • Krysto - Thursday, November 20, 2014 - link

    Because QHD represents a 78 percent increase in pixels of 1080p?

    Even if chip companies say they "support QHD" or "4k" they may do it JUST BARELY, which means you really should wait at least until the 3rd generation of a GPU "supporting QHD" before you start using QHD. Ideally you should use a GPU that is at least 4x more powerful than the one that "just barely" supports a certain resolution, to minimize stress/power consumption.
    Reply
  • psyside1 - Thursday, November 20, 2014 - link

    I bet my money that GPU is not the problem, you will see later on with updated the lag will be non existent. Reply
  • sonicmerlin - Friday, November 21, 2014 - link

    Since Android doesn't prioritize the UI thread that's not possible Reply
  • lilmoe - Thursday, November 20, 2014 - link

    +999

    I've been particularly loud about this subject for the past year. Mobile GPUs are at least 2 generations behind compared to current mobile screen resolutions IMHO. The resolution spec race *above a certain point* is mobile experience's worst enemy. I believe Snapdragon 801 (and similar) GPUs are PERFECT for 720p. On the other hand, Snapdragon 805 (and current Mali T760MP6) is great for 1080p max.

    Mind you, current ~5" 1080p panels are far from perfect, and consumers will appreciate more improvement to these panels instead of higher resolutions, especially since we've reached a point of diminishing returns on anything above 440ppi. If someone can tell the sub-pixels apart on a 5" 1080p panel it'll most likely be due to pentile or similar sub-pixel arrangements.

    I seriously hope OEMs like Samsung, Sony, and HTC stick with 5-5.2" 1080p panels for 2015 so we can actually FEEL the difference 20nm and ARMv8 chips will have to offer. We're BARELY noticing the performance and efficiency benefits of the newer silicon. Or at least (for God's sake) allow us to revert back to 720p in the power options if they opt for 1440p panels (since we'll have perfect scaling that way, and arguably better 720p panels at that :P . You know, since each pixel will have significantly more sub-pixels in a 1440p panel running at 720p).

    I'll be picking up (and recommending) whoever sticks with 1080p in a decent flagship in 2015. They'll all have 64bit processors and faster AES anyway, so this article's issues won't be a problem for any of these flagships.
    Reply
  • Endda - Thursday, November 20, 2014 - link

    "I'll be picking up (and recommending) whoever sticks with 1080p in a decent flagship in 2015."

    I highly doubt any of the major Android OEMs(Sony, Motorola, HTC, Samsung or LG) will use a 1080p display in their actual flagship smartphone in 2015
    Reply
  • phoenix_rizzen - Thursday, November 20, 2014 - link

    Considering their Compact versions tend to be one screen resolution lower than the full-sized Xperia, if the Z4 is 1440p next year, then the Z4 Compact should be 1080p. :) Reply
  • tralalalalalala40 - Friday, November 21, 2014 - link

    So finally admitting only Apple is doing it right :) Reply
  • lilmoe - Saturday, November 22, 2014 - link

    "Admitting" isn't quite what it is. I've mentioned several times before that I like their "current" CPU/GPU to screen resolution configurations. But that doesn't mean Apple is doing that for the sake of what I mentioned above. Don't forget that the iPhone 4/4S had a relatively underpowered GPU/CPU pushing its resolution, and the same true about the first two retina iPads... It's only NOW that their SoCs are keeping up with the resolutions they have on their devices, and it's only recently that iOS can somewhat handle non-doubled-scaling to certain point (not perfectly though). Again, it's not that Apple are "doing it right", it's more like there isn't any way else they can do it, and I so to happen the "current" configuration. Reply
  • tralalalalalala40 - Saturday, November 22, 2014 - link

    I would argue that they are doing it for that sake. Retina display was a statement: after this, you get hugely diminishing returns. Let's focus on the fastest UI possible and implement with compiled apps! (yay no ART!) Reply
  • phoenix_rizzen - Thursday, November 27, 2014 - link

    This is something that's bugged me about Android phone OEMs: pushing the GPUs to their max, instead of using "too much GPU" for the resolution.

    A Snapdragon 800 or 801 (Adreno 330) with a 720p screen would fly. Instead, they're saddled with 1080p screens where they aren't always smooth.

    A Snapdragon 805 (Adreno 420) with a 1080p screen would fly. Instead, they're saddled with 1440p screen where they aren't always smooth.

    And so on.

    Just because a GPU "supports" a resolution doesn't mean it should be run at that resolution. Even "supporting" a resolution at 60 fps isn't enough these days.
    Reply

Log in

Don't have an account? Sign up now