We finally did something about [Ember on] Android Performance | Hacker News Reader

We finally did something about [Ember on] Android Performance

eviltrout.com

45 pointslreeves7 comments

One reason this was kind of urgent for us is:

1. The prevalance of low-end Android devices

2. The dominance of Android worldwide, e.g. http://www.idc.com/prodserv/smartphone-os-market-share.jsp shows 2015Q2, android 82.8%, iOS 13.9%, everything else ~3%

We've also been working with Google to see what they can do to make Android/Chrome performance better with complex JavaScript like Ember and Angular. Chrome 45 improved things about 25% which is great, but when you start 500 to 800% slower, there's a long way to go..

Complex JavaScript performance on iOS is, and remains, amazing and stellar. Problem is not much of the world is on iOS.

Adding insult to injury, 2015 was also an abysmal year for Android performance, largely due to Qualcomm, uh, how do I say this... sucking.

"I don't think there's any way to sugarcoat this, but 2015 has not been a particularly great year for Qualcomm in the high-end SoC business" -- http://www.anandtech.com/show/9837/snapdragon-820-preview

If you compare geekbench single threaded performance numbers, you can sure see why Google is anxious to build their own silicon.

>you can sure see why Google is anxious to build their own silicon

This can't come too soon.

Even for native development, the Nexus 6P is a bit disappointing. It does have a lot of pixels to carry around but still its real life performances are not up to what I would expect.

Could not sign-in/create account to the blog comment thingy, so asking here:

Is there performance numbers available per browser in Android somewhere and to which browser the mentioned numbers apply?

Traditionally the vendor shipped browsers in Android are abysmal, out of date, probably insecure and not standards compliant. So what I am really interested about is stock Google Chrome or Firefox performance. And if these numbers are from either one of those, it would be nice to know.

Firefox on Android is much slower in every JS test I've ever seen. We only test against Chrome on Android. The 5x perf improvement is across the board but slower devices benefit much more. You may not notice a 200ms improvement on say an iPhone 6, but you will sure notice a 1000ms improvement, or more, on older and slower android devices.

Out of curiosity, why did you use a custom virtual-DOM implementation instead of one like React?

It's perhaps not as custom as I made it sound. The code we have is a wrapper around the [virtual-dom](https://github.com/Matt-Esch/virtual-dom) library which does most of the low level work.

The "widget" framework is a series of simple ES6 classes that allow us to keep state around and delegate events as actions up to Ember controllers. We had a lot of pre-existing, battle tested code that was written using Ember idioms and was not a performance problem, so we kept that around and used the virtual dom stuff just for rendering HTML as fast as possible.

Why not React? Our main pain point was rendering, and we didn't need all the extra stuff React provided as those bases were already covered by Ember. Why include 26k min+gzip when we would only use a small part of it that was already provided by another excellent virtual-dom library?

Reply on news.ycombinator.com