We finally did something about Android Performance - Evil Trout's Blog


#1

Back in September, Codinghorror wrote a popular post on the state of android Javascript performance on Discourse’s Meta forum. It drew a lot of attention, and led to some fascinating discussions on our forum and behind the scenes with browser engineers.


This is a companion discussion topic for the original entry at https://eviltrout.com/2016/02/25/fixing-android-performance.html

#2

Nice strategy! Expected initial rendering to have a better improvement ratio then rerender, but it doesn’t look like that was the result. What was the improvement on iOS when compared to before?


#3

We don’t typically look at iOS performance any more since it’s so crazily good… for example:

  • Phone 5 → 340ms
  • iPhone 5s → 175ms
  • iPhone 6 → 140ms
  • iPad Air 2 → 120ms
  • iPhone 6s → 60-70ms

The very best Android devices manage about 300ms in this test, and that’s assuming you have a late 2015 / 2016 device fully up to date in the OS and browser.

I checked the iPad Pro and it’s around 50ms so there is a point of diminishing returns on iOS.


#4

That is a lot of work you did there.
I can see that you are still on Ember 1.12.2 - that is A - pretty old, B - is ‘pre glimmer’

Have you thought of upgrading to Ember 2.3 and checking what Glimmer has to offer you?
Especially that Glimmer 2.0 is ‘around the corner’ that is said to speed up the initial render.

You can read a bit more about Glimmer here: https://is-ember-fast-yet.firebaseapp.com/


#5

Currently, all Ember builds post 1.12 are 2x slower in our benchmarks for initial render, and that’s unacceptable for us to upgrade to.

The upcoming Glimmer (prev Glimmer v2) looks quite promising, and if it brings Ember back to the speeds it had in the 1.11-1.12 releases we’ll certainly upgrade to it.

In the meantime I plan to keep us somewhat compatible with future upgrades, but I haven’t had a chance to review our APIs yet as I was quite busy with the vdom stuff!


#6

I haven’t read enough about FastBoot, but isn’t initial performance something that it should be supposed to solve? Did you consider using FastBoot? (Or do you think it’s too early perhaps?) Or maybe it doesn’t fit your scenarios at all?


#7

FastBoot is very cool, but not something that would be easy to get working in Discourse at this point. We use a lot of jQuery and didInsertElement hooks which are not supported. On top of that, we’d have to get a node.js server running inside our container, so there’s a bunch of operations costs involved in setting that up.

Also, it wouldn’t fully close the performance gap we’re facing with the Ember 2.x branch. Leaving and entering a topic would use the initial render code path, even if FastBoot was running to bootstrap the application.


#8

There’s at least two ways to make this nicer. You could use hyperscript-helpers to remove those h, but to make it look even more like templates, try JSX to Virtual Hyperscript Babel transform.