I got 269ms & 259ms with s6 edge + (note 5). Is that an usual score for this device? Just went through a system software update last week.
Android 5.1.1 Chrome 49.0.2
Wouldn’t the main architectural difference ie less cores higher single threaded perf be the main factor at play here? It seems less like an issue of android catching up to Apple than ember not scaling well across multicore devices.
Here is a deeper dive into the differences between the two different processors you might get in a Samsung S7:
Differences in scores dependant on task, note the Sunspider score.
s/ember/javascript/g
You can use webworkers, but it’s tricky to isolate method and pass the messages arounds.
I think you’re analysis and fear of this only being able to solved via hardware is off. Your real problem is that javascript is a single threaded language and most JS engines are still single threaded. The multiple cores on the typical android hardware is ill suited for javascript. But this can hopefully be mitigated in two ways: 1) there are already some javascript extensions that expose multi-threading, if google adopts one of these and you were willing to rewrite some of your javascript to be multi-threaded you could boost performance. 2) If you’re really lucky google might start to embrace multi-threading in the javascript engine itself, giving you a performance boost without needing to do any work.
The move to multiple cores is something that google has been aware of and pushing for a while now, and google knows that the future is javascript, and that future must involve taking advantage of all of the capabilites of the platform. I think you’ll find that a multithreaded JS engine and language extensions are coming.
It’s plenty fast on iOS. Benchmark it yourself if you don’t believe me. Come back and post numbers if you dare 
Apple is a full year ahead in hardware, because Qualcomm had an awful year:
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. The company remains a leading SoC developer, but Snapdragon 810, the company’s first ARMv8 AArch64-capable SoC, did not live up to expectations
Even the 820, which is better – thankfully! – is not even as fast as the old iPhone 6, much less the new 6s. And the iPhone 7 will be shipping in less than 6 months with an even faster CPU.
This idea that there is some magic in multithreading is just not backed up by benchmark data for typical apps outside of video encoding. If your cores are all slow, it doesn’t matter if you have 24, 48, or a million of them.
I saw [this discussion on Hacker News] (The Chrome Distortion: how Chrome negatively alters our expectations | Hacker News) today, where one of the points made regarding the performance of various JavaScript frameworks in V8 is that Ember is apparently not as good as others, at least according to some benchmarks. The discussion is about the post The Chrome Distortion: how Chrome negatively alters our expectations by Chris Thoburn.
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.
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…
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?
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…
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?
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…
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.
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?
There are two things to look at
Geekbench single core perf
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. 
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.
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:
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.
It was a oneplus 5, which I no longer have, I bought it as an off to college gift for my nephew.
