The State of JavaScript on Android in 2015 is... poor

(Paolo G. Giarrusso) #235

Thanks for the link, but allow me to rant against the authors. If you want to post one JavaScript benchmark, why on Earth would you post SunSpider?

ArsTechnica also uses other browsing benchmarks together with SunSpider; surprisingly, all three show a smaller but consistent advantage for the Exynos (using SunSpider, 532 ms vs 632 ms; Octane has them at 9143 vs 11115). Look yourself for complete tables and comparisons with modern iPhones.

(Luke Scammell) #236

Dare we hope that Android N might fix some of these issues? Obviously this still won’t help most of the existing 1 billion android users…

(Al Willis) #237

It should be noted that not only is Apple ahead in hardware; they’ve also been cranking away on their JavaScript engine as well. The latest is an even faster replacement for their LLVM backend with a new B3 backend.

You can read all about it (if you’re into that sort of thing) at Introducing the B3 JIT Compiler.

Even though Apple gets knocked a lot for apparently not focusing on web stuff as much as they could, the combination of their processor designs and their work on JavaScript Core gives them a substantial advantage with JavaScript applications for the foreseeable future. WWDC is next week; should be interesting what other web goodies get revealed.


[quote=“lukescammell, post:236, topic:33889, full:true”]
Dare we hope that Android N might fix some of these issues? Obviously this still won’t help most of the existing 1 billion android users…
[/quote] Yeah I was wondering about Android N, too. Who knows what percentage of existing Android phones will even have the chance to run the new OS given how slack many carriers are with updates, etc?

(Luke Scammell) #239

Meh, doesn’t matter. Brand new OnePlus 3, Snapdragon 820, Chrome 51, Android 6.0.1 and it does 400ms on complex HTML. Disappointing, disappointing.

Phone’s great for £309 and really doesn’t feel that slow. I’m starting to think it’s just Chrome being utter rubbish compared to safari in mobile…

(Jeff Atwood) #240

Android JS perf is somewhat less relevant since we switched to a raw vdom renderer in 1.5 final for the topic page and the header, which provides 6x-8x the performance on slower Android devices over Ember.

The OnePlus 3 is a great device! Still, it will be nice to see if Android can close the considerable JS performance gap in 2017, with whatever new CPUs are coming out, perhaps Snapdragon 830?

(Jeff Atwood) #241

Wait, I did not realize snapdragon 820 does about 2400 on geekbench single core putting it, in theory, within range of an iPhone 6s for single core perf! So yeah that is hugely disappointing.

The snapdragon 821 appearing in this years Nexus devices will be about 10% faster still, but then the iPhone 7 this year will likely be considerably more than 10% faster than the iPhone 6s as well…

(Luke Scammell) #242

I can tell you that the 820 doesn’t NOT feel in any way shape or form slow in Android 6.0.1 on pretty much any other app I have thrown at it.

A heavy user iPhone 6s friend was impressed after using it for an hour or two and commented how he thought Android was supposed to be difficult to use and slow, saying he thought it made the (admittedly year old) 6s feel sluggish in places.

I’m just reporting what was commented to me 3rd hand as I don’t have any recent iPhone experience and it might just be the superior multitasking handling of Android for a heavy user, who knows. But the Javascript on Android is still a crushing disappointment.

However, given the relatively strong showing of both the Snapdragon 820 and Samsung’s Exynos 8890 in pretty much every other metric, I’m starting to think it’s Google and Chrome holding back Javascript on Android more than the hardware now. Obviously Apple’s hardware is still superior and probably will remain so for the foreseeable future due to complete vertical integration, but from other metrics it shouldn’t be THIS much better.

(Jeff Atwood) #243

Some of it was definitely Chrome optimization. Compare December 2015 early test 820 benches…

With the final Samsung s7 release on Chrome 4 months later:

Clearly much faster and anandtech said Qualcomm specifically cautioned them about this Chrome optimization issue in Dec 2015.


I’ve ended up reading this thread before while wondering why my phone (Galaxy s4) sometimes takes a while to browse on Discourse. I’ve tried some different browsers and that has produced good results (Puffin specifically being surprisingly fast compared to the default browser I had been using).

I’m upgrading to a new phone soon and was poking through benchmarks to see which ones might perform best with Discourse. It’s not a particularly big deal, but it’s the most important QoL feature for me. I’m not sure if this is the right place to ask (I couldn’t find any more relevant threads), but given the improvements made to Discourse on this front I wanted to ask if anyone had any new data on which phones generally would perform best when browsing Discourse? What phone specifications tend to make browsing a better experience?

(Jeff Atwood) #245

There are two things to look at

  1. Geekbench single core perf

  2. General JS perf on the dominant browser on the platform

Unfortunately Android is in the doghouse on both at the moment, still, even in 2016. If you want to have a good cry, compare those numbers for iPhone 7, hell even the year old iPhone 6s, and literally anything in Android world. :sob:

The only real good news is Discourse 1.5 switched to vdom rendering on core pages, which was a solid 5x perf increase on Android, and Ember 2.10 looks 2x faster on Android, and we think we will be able to get to that version of Ember in this current 1.7 beta, and thus in the 1.7 release later this year.

(Jeff Atwood) #246

In mid-2017, Chrome has finally gotten their act together on Javascript – benchmarks shown below are on a Nexus 6p:

Read the official Google followup as well … all of this went into the Turbofan and Ignition release in Chrome 59.

Combined with the snapdragon 835 we’re finally entering obama-not-bad.gif territory, where a recent Android device (90ms) is at least in the ballpark of an iPhone 6s (60-70ms) when on Chrome latest, currently 59:

(Luke Scammell) #247

Out of interest, which SD 835 device is that from?

My SD 820-based Android 7.1.1 OP3 is only pulling 200/180ms in Chrome 59/Canary 60 on the ember benchmarks and 24.2 on Speedometer, which is even slower than the SD 810-based Nexus 6p.

This isn’t a clean device, but I did clear out all running apps and reboot before running, and got rid of all but 8 tabs in Chrome.

(Jeff Atwood) #248

It was a oneplus 5, which I no longer have, I bought it as an off to college gift for my nephew.

(Jeff Atwood) #249

Impressively, I just tested @zogstrip’s Nexus 6p on, render complex list, 2.11 and I got ~150ms. That’s quite good.

Chrome 55 212 ms
Chrome 58 175 ms
Chrome 61 150ms

That puts it in iPhone 6 territory, which is about where it should be based on the CPU, and I would rate it as solidly “good”. The Nexus 6p is not exactly a new device… we’ll see where Snapdragon 845 takes us. Current rumors say:

The Snapdragon 845 scores 2600+ in GeekBench 4, for single core results.

That’s about 10% faster than iPhone 6s.

(Dean Taylor) #250

For those that are not familiar with why Apple devices show higher performance and why Android device manufacturers appear to be playing catch-up here is a nice video with a little bit of history:

For point of reference I ran some of the benchmarks on my OnePlus 2 (ONE A2003) an August 2015 Qualcomm Snapdragon 810 phone - the same processor as the Nexus 6P mentioned above.
This was a new phone when this thread was started back in 2015, now updated the phone running on a custom Lineage OS build (Android 7.1.2). In a months time a replacement phone will come and I’ll reset the device to whatever the latest manufacturer OS is and run these numbers again.

Browser version “render complex list”, 2.11 Speedometer
Chrome 61 (Stable) 152.27ms 27.2 (±2.4)
Chrome 62 (Beta) 179.04ms 25.4 (±1.4)
Chrome 63 (Canary) 190.00ms 23.7 (±1.7)

Allowing the phone to “cool” between benchmark runs - these are pretty repeatable numbers.

Hopefully this doesn’t indicate that Chrome is slipping backwards any when Chrome 63 finally reaches the general public.

(Jeff Atwood) #251

Canary isn’t a good test candidate. Try beta. Canary is too variable. Also you don’t need both runs, the HTML and regular are pretty much the same these days.

(Dean Taylor) #252

I’ve updated the post above to include the Chrome Beta numbers too.

(Jeff Atwood) #253

Well that is concerning. I am not on Twitter any more but you might try pinging Benedikt with a link to your post

Add collapse expanded posts at bottom / top
(Dean Taylor) #254