Play Store App Updates

One of the most demanding real-world tasks on Android is the installing and updating of applications. Doing mass-updates on several applications at once can heat up most devices as we see heavy computational load not only in the install process, but also caused by ART's ahead-of-time compilation and optimization process.

I recorded a ~80s period where the Play Store updated several installation packages, such as Android's WebView component as well as a few other user-applications.

The Play Store update process seems to be extremely liberal with spawning threads. The little cores are severely over-capacity as we see package updates loading up to 8-9 threads onto the cluster. The two major peaks towards the end of the log especially demonstrate this fact as all CPUs vastly exceed the optimal run-queue depth of 1 when under load, which causes the scheduler to need to preemt between multiple processes.

While it may have been intriguing to see the little cores loaded to such extent, the big cluster seems outright shocking as it as well sees very significant thread-placement. This is one of the rare scenarios where having 4 big cores is not enough. Similarly to the little cores, we see peaks where the run-queue depth vastly exceeds the optimal value of 1.

When looking at the total system run-queue depth, things look for a lack of better description, quite ridiculous. We routinely have peaks where all 8 cores of the system are fully loaded and peak at over 10 threads. It looks like Google is able to massively parallelize the app update process and take advantage of even the highest core-count SoCs. This scenario is absolutely about maximum throughput and performance while utilizing all available hardware resources.

App: Play Store Open & Scroll Camera: Launch
Comments Locked

157 Comments

View All Comments

  • nightbringer57 - Tuesday, September 1, 2015 - link

    Very interesting article, much more favourable to multi-core designs than I would have thought.

    Each article page must have cost an insane amount of time. However, I still feel like some more information could have been useful. This article is geared towards real-world use cases, but I think it would be interesting to repeat this analysis on a few commonly-used benchmarking apps. I feel like this would be interesting to compare them to real-world uses and may help understanding the results.
  • ingwe - Tuesday, September 1, 2015 - link

    Yes that would be very interesting. I am always curious about how synthetics actually compare to more real world applications.
  • Azethoth - Thursday, September 3, 2015 - link

    Every single synthetic I have ever seen vastly exaggerates the benefit. I would be interested in an actual real world use case that actually matches a synthetic. It would blow my mind if there are any.
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    I'll do a follow-up pipeline on this if the interest is high enough.
  • bug77 - Tuesday, September 1, 2015 - link

    High enough +1.
    Please do the follow-up.
  • tipoo - Tuesday, September 1, 2015 - link

    I'd definitely be interested.
  • Drumsticks - Tuesday, September 1, 2015 - link

    Yes! This would be neat. Also, great article!
  • ThisIsChrisKim - Tuesday, September 1, 2015 - link

    Yes, Would love a follow-up.
  • HanakoIkezawa - Tuesday, September 1, 2015 - link

    I'm not sure of the practicality, but I would love to see a follow-up with Denver k1 and the A8X to see how lower core count out of order and in order SoCs are handled.

    This seriously was a fantastic article Andrei!
  • kspirit - Tuesday, September 1, 2015 - link

    Yes please! +1

Log in

Don't have an account? Sign up now