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

(Dean Taylor) #209

This might be a difficult task to find someone prepared to take on this task…

…but perhaps someone on the Chrome team would be prepared to be a “Chromium Perf Sheriff” for a specific test for this issue.

You can see the Chrome Performance Dashboard, this highlights regressions and improvements, this even highlights the specific (range of) code that caused the improvement or regression.

Higher visibility of the performance issue would be beneficial and the automated testing across standardised Google Android devices.

It’s not just about seeing improvements it’s also about ensuring there are not regressions and things don’t get worse.

(Alec Joy) #210

Check out the single core performance of the upcoming Snapdragon 820


Not quite up with the Apple A9, but a hell of a lot closer than anything we’ve seen so far. Maybe there is hope for Ember/Js frameworks on Android after all.

(Jeff Atwood) #211

One would hope. The Anandtech numbers are a little less encouraging when they tested against actual JS benchmarks.

Still, better – Qualcomm basically sucking for the entire year of 2015 did not help matters.

(Alec Joy) #212

true, but step 1 is getting the single core performance up. There’s still a lot of work to do on the software side but hopefully this starts a trend of Android chip makers keep the single core performance up and trying to get to parody with Apple’s chips. From there there’s still plenty of work to do in V8, but hardware needed to be there too.

Half of the puzzle is getting better, at least. Now it’s Google’s turn.

(Kevin P. Fleming) #213

Let’s hope they get ‘parity’, although ‘parody’ would be sufficient to improve the situation at this point :smile:

(Demetri Obenour) #214

The real solution might be a combination: render some stuff server-side, use an unbound renderer, and use web workers.

(Dean Taylor) #215

This kind of problem gets me wondering…

… Is there such a thing as a trust-worthy bug / feature implementation bounty programme that could be used to target this V8 / Chrome / Chromium issue?

There would need to be some quite specific requirements.

I would throw £20 (~$30 USD) in personally without even thinking about it…
… the number of man hours lost reading this and other threads and dealing with user complaints must add up.

It would mean more eyeballs on the problem - I just wouldn’t want the additional attention to be too distracting for any Google developers that might be already working on the issue - although I don’t believe there is any commitment of solid time on the issue.

(Alec Joy) #216

This is basically what Angular 2.0 is doing, and to my knowledge it’s more or less what React does. We’ll see if Ember jumps on that particular bandwagon, Fastboot is still very much a work in progress but who knows what they have planned.

(ksec) #217

I cant help but laugh at the post you were replying to, suggesting Apple cheated, or buy into ARM. ROFL. Then i saw he got 6 likes… people do believe this shxt. Sigh…

The ARMv8 implementation design started in 2007, picking up speed in late 2009. Announced to the public in late 2011, Apple shipped their first 64Bit Soc with iPhone 5S in late 2013.
This doesn’t mean ARMv8 were unknown to the world before then, like you have said, ARM generally consult and work with their partners on many things; If not everything, that is why they have many implementation and reference design to suit their customer’s needs. And this is not only on hardware, but software as well such as compiler programmers.

Any other company with an ARM architecture license, would likely to have been involved in the design stage. And if they could be bothered to actually work on 64bit design all the way from the start, there is no reason why they cant ship their SoC in 2013 or 2014!

So why were everyone on the market 2 years late on ARMv8 64bit? Well it take 1- 2 years to get an implementation of an Architecture, and then another 6 months to tape out. Even ARM didn’t have their ARMv8 reference design finish when Apple shipped A7. It wasn’t just the competitors were shock, it was a shock to ARM as well. Because NO ONE, absolutely NO ONE think they will need 64bit, not yet, not then, not on a Smartphone.

Qualcomm’s Anand Chandrasekher actually got demoted for saying 64bit is not needed. He was properly right, but Qualcomm was under pressure from their customers / shareholders to offer 64bit chip so he was not allowed to say that. ARM was under intense pressure as well, and to fast track the whole ARMv8 reference design.

(Roger Shepherd) #218

We agree!

I claim no first hand knowledge but I am inclined to agree that ARM were also surprised - if the the input from their customers had been that 64-bits was needed ARM would have moved faster. This illustrates a problem that the ARM ecosystem has - the ecosystem is not a substitute for a single vertically integrated company when it comes to understand the full stack. Perhaps Qualcomm understand phone software well (although I doubt it) - but certainly they didn’t understand the potential of 64-bit, and the other phone chip companies who are ARM licensees have no depth in software.

Another of your points - Apple decided to move early - other could have but didn’t.

(Alex Popa) #219

Android’s browser not only suck in JS performance, but they suck at CSS animations and have extra oddities to deal with (VH for instance as the top bar collapses). Its baffling how great Chrome is on desktop, and how little they care about it on mobile. Clearly its doable on mobile because iOS does it. That’s why when you compare the top Android tablet to a 2-3 year old iPad on webbrowsing the iPad almost always wins (unless it runs out of memory).

(Paolo G. Giarrusso) #220

There might be hope for Android’s future. According to the news below (from Ars Technica, which I find much above average clickbait), Google plans to also build its own processors (and hired semiconductors engineers from PA Semi). Hopefully they’d have better single-core performance than Qualcomm’s octacore CPUs:

(Alex Popa) #221

Little late to the party but we’ll take it! :smiley:

(Dave McClure) #222

Like a good internet citizen, I pass this link along without having made a real attempt to fully read it or understand it:

B3 generates code that is as good as LLVM on the benchmarks we tried, and makes WebKit faster overall by reducing the amount of time spent compiling. We’re happy to have enabled the new B3 compiler in the FTL JIT. Having our own low-level compiler backend gives us an immediate boost on some benchmarks. We hope that in the future it will allow us to better tune our compiler infrastructure for the web.

B3 is not yet complete. We still need to finish porting B3 to ARM64. B3 passes all tests, but we haven’t finished optimizing performance on ARM. Once all platforms that used the FTL switch to B3, we plan to remove LLVM support from the FTL JIT.

(Erlend Sogge Heggen) #223

Not very relevant to Android. Always nice to hear about JavaScript getting faster though :slightly_smiling:

The biggest short-term improvement to Android speeds is coming from Discourse itself, in the form of vdom:

This is going to be huge, and I really hope the official announcement (@eviltrout will do a proper writeup in a blog post) sparks further debate about the state of JS on Android and what’s being done to improve it on every part of the stack – Discourse, Ember, Chrome and Android.

(Rafael dos Santos Silva) #224

This will make the first hit on Discouse (where we download a lot of js, parse and compile) 500% faster and normal JS execution 10% faster.

But looks like it’s only for OSX for the moment.

(Dave McClure) #225

Only relevant in that it could make Android seem slower yet again, in comparison to Apple :slightly_smiling:


speaking of work on V8 engine, Addy Osmani posted:

New V8 JavaScript performance improvements
Object.keys() is now up to 2x faster
ES6 rest parameters are up to 8-10x faster
Object.assign() ~ as fast as _.assign()

more detail to come

(Jeff Atwood) #227

Robin’s blog post about switching out Ember rendering for vdom on topics is now live, and has benchmark numbers for Android

(Jeff Atwood) #228

In a bizarre turn of events, the Samsung S7 Exynos (non-US) is quite a bit faster here, about 170ms on complex list… but the Samsung S7 Qualcomm Snapdragon 820 (US) scores a mind-bending 750ms? I have to assume it’s something about Chrome / Android that can’t deal with the new CPU?

Scores can be found by following this tweet:

Good Job Android, you caught up to the iPhone 5s! Well, sometimes! :wink: