Given the bench site hasn’t run correctly against glimmer2 or even glimmer for a while, I’m dubious of this check.
On Android devices I’ve given up trying to get decent performance with heaps of dom elements. Instead I changed my approach and looked into reducing the amount I was trying to render (and the amount of data I was requesting).
As an example, instead of loading all contacts on the contacts page, I fetched only the first 10 by default and loaded another 10 each time the user scrolled to the bottom of the list. I combined that with some inViewport checking so as the contacts scrolled out of view their component only rendered an empty div.
I also put an inviting search bar at the top that runs a live request to the server.
It’s not always possible to channel user behaviour like that but it might be an option 
Here’s results on the Google Pixel phone (brand new, Snapdragon 821) and iPhone 7+ on Ember 1.12 and 2.8
In this case it is 10x slower, using Android Chrome Beta. I tried regular and Dev channels and got the same result.
Did you try last beta (2.10.2)? It should have Glimmer2 enabled by default.
Looks better for sure. Android is still 10x slower, sadly. Google Pixel phone on left, iPhone 7 on right.
2 Likes
An excellent blog post outlining hope for Android:
http://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks
There’s a new browser benchmark which is considered much more representative of today’s webapps:
http://browserbench.org/Speedometer/
Some results:
Skylake i7 Chrome 184
iPhone 7 111
iPad Pro 85
iPhone 6s 82
Skylake i7 FF / Edge 64 (same result)
iPad Air 2 48
iPhone 5s 32
OnePlus3 24
Nexus 6p 23
Google Pixel Phone 20
Nexus 5x 15
Galaxy S7 12
2013 Moto X 10
2012 Nexus 7 10
iPhone 4s 10
iPhone 4 3
(Some Android users report up to about 29 score on very new late 2016 Android devices, depending on the vagaries of the browser used. Still below the 2013 iPhone 5s which can be purchased used for about $150 these days.)
Ember.js is one part of the Speedometer test. Let’s drill into that. Here’s the latest version of Ember.js (2.10) comparing Google Pixel phone and iPhone 7, latest updates on all – on http://emberperf.eviltrout.com/
Note that earlier versions of Ember, prior to 2.10 and Glimmer 2, were 15x slower on Android so being “only” 10x slower than iOS is … actually an improvement.
But, good news – they’re looking and they have a new benchmark to target that actually includes ember.js! They’ve said many of the key optimizations in Chrome/Android should land in 2017, probably 1st half.
Let me just say that cough I am SUPER looking forward to the year 2017 for Android/Chrome.
Fascinating Nexus 5, Nexus 6p, Nexus 7, and Nexus 9 results – look how much faster Ember 2.10 is on the Nvidia Tegra hardware.
How is virtual-dom powered discourse widgets compares to glimmer2 , on android now ?
Since we are building a chat-room , i guess we will need it. But we will try smoke and mirror first . Why SnM is not applicable for discourse ?
The vdom hot path of the codebase was about 6x faster across the board, so even with recent ember improvements it doesn’t make sense to rewrite it in glimmer 2.
Having said that, it would be lovely if in the future ember got so fast that I could ditch that code - it’s much harder to write the HTML widgets by hand than using handlebars is 
We do the occlusion stuff ourself in the vdom part. Before that we had our own system for doing that which I called cloaking. It’s much faster to only render what’s on screen, but it’s even faster still to have vdom stuff.
2 Likes
Very interesting , any chance of releasing that as an addon ?
Any news on this problem ?
Chrome 59 is now out with TurboFan and Ignition working:
Improvements are kind of modest on Android phones, though… up to about 20%, less so on older devices.
Not very good results with a so powerful chipset
Qualcomm is years behind Apple on raw performance, unfortunately. Even their latest SoC is just not very fast in absolute terms.
Anyway it’s mainly a V8 issue if I understand correctly
Partially, but the software side is now more or less resolved (scroll up and look at the screenshots I posted). As for hardware, look at geekbench 4 single threaded results (all JS is single threaded) and compare. Apple is at 2x what Qualcomm can deliver. Most Qualcomm SoCs in phones today are barely at iPhone 6 perf levels.