Why is Ember 3x - 5x slower on Android?


#62

How is virtual-dom powered discourse widgets compares to glimmer2 , on android now ?


#63

You would need to ask @eviltrout but last time we checked, many times faster still.


#64

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 ?


#65

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 :slight_smile:

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.


#66

Very interesting , any chance of releasing that as an addon ?


#67

Any news on this problem ?


#68

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.


#69

This is on Nexus 6p. We are seeing some excellent improvements in recent Chrome versions:


#70

On a Snapdragon 835 device, Chrome latest (59).


#71

Not very good results with a so powerful chipset


#72

Qualcomm is years behind Apple on raw performance, unfortunately. Even their latest SoC is just not very fast in absolute terms.


#73

Anyway it’s mainly a V8 issue if I understand correctly


#74

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.


#75

I just happened to be going through some old blog posts I wrote and saw a reference to this thread. Interesting to see it still going 2 years later. While there are architecture changes that can be made to optimize performance, the reality is JavaScript is an expensive task. Mobile phones have slower processors. Even if they are marketing as quad-core,blah blah, they are always underclocked because of batteries. In fact most phones are automatically slower if they are not plugged in. The best practice is ti minimize the amount of JavaScript used. This means using fast food frameworks is a big performance hit. I know that won’t be popular here, but if you want good user experience you need to do things differently. When a browser loads a page with scripts each script must be: downloaded, evaluated, executed. Even if the code is never called by the application the browser still executes every single line because it needs to know if the script is going to change the DOM integrity. So minimize the amount of code that must be execute. this is why far too many sites take 5-30 seconds to load :frowning:


#76

Not true; look up benchmarks on the Apple iPhone 7. It’s damn near a laptop processor at this point. And the iPhone 8 (A11) has yet to be released, not to mention iPhones 9 and 10…


#77

iPhone 8 benchmarks are out and here’s a summary…

image

The “bad news” is that iPhone 7 was already so fast that for Ember, we’ve definitely reached the point of saturation where further perf increases on the iOS side aren’t getting us much.

We are still laughably far from that on the Android side, BUT good news, as of Chrome 60+, we see 2x the real world Android JavaScript performance thanks to TurboFan and Ignition reaching maturity. This means a modest device like the Nexus 6p can deliver roughly the same performance as an iPhone 6, and a brand new Snapdragon 835 device gets within ~33% of an iPhone 6s.

Checking my prior results for ember 2.10, render complex list, using Chrome latest on each:

Nexus 5 – 413ms → 325ms
Nexus 7 – 673ms → 585ms
Nexus 6p – 212ms → 150ms
OnePlus 5 – 90ms → 75ms