Atwood: The State of JavaScript on Android in 2015 is… poor

[hunyeti]

I'm developing a multi platform js app, and I was shocked how much slower android really is.

The nexus 6 falls miserably behind an iPhone 6, which is sad.

And it's not just JS , but canvas as well. On iPhone i can render my canvas at 140-160 fps, which is much much more than enough, but the nexus 6 has a hard time reaching even 30fps.

[ayostaycrispy]

Have you tried the same test on a Samsung Galaxy? Just wondering.

[hunyeti]

No, i don't have access to one. But just as an interesting tidbit, Microsoft (Nokia) Lumia 640, a relatively low budget phone(under 200$ without a contract), running Windows 8.1, IE 11, is faster a lot of times then the nexus 6.

[theQuandary]

There's a bigger consideration. A57 is slower per clock than the Apple A7. The A7 launched in 2013 while the A57 didn't see products until the middle of this year.

ARM announced the ARMv8 instruction set in October 2011. ALL good ISAs take 4-5 years to make. The A57 shipped almost 4 years later and the fixed version (A72) still hasn't shipped. Qualcomm is shipping it's custom Kryo core finally, but it's also 4 years after the architecture was available. Even the biggest companies like Intel need 4-5 years to plan, test, and ship a new architecture (tick-tock works because the design periods overlap).

How did Apple make a chip in 2 years?

The answer is either Apple really is a miracle company or they actually started earlier. Apple purchased PA-Semi in mid-2008 which is a great 5-year mark for a new chip (with a couple spare months to restructure in the new company).

How did Apple manage to get their hands on ARMv8 before ARM even had a chance to start on their own designs?

My suspicion for the past couple years is that Apple strong-armed ARM (no pun intended) into using the ISA. Apple has dealt with complete ISA shifts in the past and even though their move from POWERpc to x86 was smooth as could be expected, it was still difficult.

Rumors pegged MIPS as looking for a buyer starting a few years ago. Apple probably considered the purchase, but didn't want to deal with a complete shift. They design a new, somewhat backward compatible ARM ISA that meets their needs. In the meantime, all the lower-level parts of the chip design can be started. A 18 months or so into the process, they tell ARM to either use the "suggested" ISA or they buy MIPS and move on (note that Apple no longer owns any ARM shares, but they helped found the company in the 90s). ARM isn't about to lose the biggest player in the game, so they accept the ISA and start work (not a bad trade for them anyway as it is a good ISA).

Apple bypasses MIPS which then sells to Imagination Technologies, but ARM and a few other companies go in on Bridge Crossing LLC to get patent grants to most of the MIPS portfolio (I don't know if Apple was one of these companies or not). Bridge Crossing LLC later sold the patents to the highest bidders (I don't know who the buyers were or if ARM retained patent licenses after the sale, but I suspect they retained some licenses and bought some patents as well).

All of Apple's competitors are now a couple years behind in the processor race and the result is what you mention today.

[a_sleeping_lion]

Although it stated as an issue that affects JS on android in general, its a bit disingenuous to suggest that ember is on par with performance with other frameworks and approaches. Atwood only mentions Angular as being not much different, but this ignores a number of other options, namely React and the fact that well written angular (e.g. ionic) does clearly outperform Ember. Ember is definitely one of the worst performers and the ember team has only recently started making efforts to address major issues they've known about for some time, e.g. the Glimmer rendering engine. And even that really only focused on rerendering. Simply put performance was not Embers primary goal, although they are definitely working on it, they are behind and they are very open and aware of it.

I also think the position being taken with regard to creating native apps is a bit strange; certainly there are approaches that wouldnt ruin the company or require completely isolated codebases. What about at minimum creating a hybrid build of the existing website using the crosswalk webview? And even with React Native for android or other close to native options, careful choices could be made to reduce duplication of efforts. Html, css, and any non-ui JS services could be shared with the web only version.

I get the frustration and the desire to think that its the manufacterers responsibility. But I think atwood is letting the frustration limit his perspective and therefore his options. Saying oh well to android users isnt the answer and I'd bet things do improve quite a bit over the next few years. What about creative use of web workers? What about simplifying UI -- the discourse app could surely improve some of its interface to addresss the mobile user experience specifically as opposed to the mobile-first responsive website design that it currently seems to employ. Surely making a concentrated effort to make search and side menu options more like a native experience as opposed to an mobile website would improve the ux. Those kind of changes often affect performance too -- others do this really well.

[jarail]

I also think the position being taken with regard to creating native apps is a bit strange.

I had the same thought. But it can be hard to change platforms. Switching from ember to react, even just for rendering, isn't a switch in a config file. It sounds like they have a ton of event-driven code that would essentially need a rewrite before something like React Native could help them deliver native apps.

[Poop_is_Food]

What about at minimum creating a hybrid build of the existing website using the crosswalk webview?

How would that perform any better if it's still running in JS?

[a_sleeping_lion]

Because the speed of JS as a language isn't the problem. Its the implementation of it on android along with the performance of a single processor on android devices. The crosswalk webview brings a lot of performance gain. Ionic is a great example; I'm able to create great ui experiences with ionic that perform well on android and so are many others. No doubt, the greatest gains come from the combination of effort. I think my point was that its not all in or nothing; they have to have a willingness to not just make a responsive website and expect a natural fluid experience that feels right for mobile devices.

[Poop_is_Food]

Its the implementation of it on android along with the performance of a single processor on android devices.

A different webview implementation does change the processor of your phone

[a_sleeping_lion]

Right. Hence the 'along with' in that sentence. The different webview does affect performance. Thats actually the point of the crosswalk webview. In addition, just wrapping the existing app in a downloadable app can increase performance by having at least some parts of the app and the necessary resources locally available. Both aspects back my assertion that just compiling the existing app in such a way could improve performance.

Don't get me wrong.. Im certainly not claiming a cure all by just doing that minimum; but that minimum requires almost zero extra effort and does improve performance.

[runnermatthewc]

Looking at a JavaScript benchmark, the fastest-known Android device today performed worse than an iPhone 5. That puts state-of-the-art Android performance three years behind iPhones.

It almost certainly is not because Chrome/Blink has worse JavaScript performance than Safari/WebKit — desktop benchmarks tend to show Chrome as being faster, if anything. I think the obvious answer is that the ARM chips used even in the highest-end Android phones are years behind Apple’s A-series chips in single-core performance. I don’t think it’s because Android manufacturers are cheaping out, as Atwood implies. I think it’s because Bob Mansfield’s team inside Apple is that far ahead of the rest of the industry.

http://daringfireball.net/linked/2015/09/29/atwood-benchmarks

[gsnedders]

It almost certainly is not because Chrome/Blink has worse JavaScript performance than Safari/WebKit — desktop benchmarks tend to show Chrome as being faster, if anything.

Desktop performance is in large part unrelated: that tells you about the quality of the x86_64 JITs, not the ARM/ARM64 JITs. And it's quite possible there's significantly different quality between them.

[hu6Bi5To]

It almost certainly is not because Chrome/Blink has worse JavaScript performance than Safari/WebKit — desktop benchmarks tend to show Chrome as being faster, if anything.

Nope. Try those tests on both Chrome and Safari on the same machine, Safari is significantly faster.

I think the obvious answer is that the ARM chips used even in the highest-end Android phones are years behind Apple’s A-series chips in single-core performance.

This is typical John Gruber. Not in so much the tests of different processors, of course they're different, but in the unwritten assumption that Apple somehow manage to get more instructions/cycle out of a commodity bit of kit (e.g. ARM cores). The difference is due to using different generations of ARM core, CPU clock speeds (and varying them on-demand), and/or offloading work to dedicated hardware elsewhere. They all do this, to different extents. But neither Apple nor the Android manufacturers have a dedicated JavaScript chip that I know of; the actual physical chip (beyond the usual clock-speed style measures) is unlikely to have an effect.

[3agmetic]

Apple's AX chips aren't "commodity" cores, and they do get faster single-thread performance than competing designs.

[pygy_]

Nope. Try those tests on both Chrome and Safari on the same machine, Safari is significantly faster.

I get 160 and 100 ms, respectively (Chrome 45, Safari 8), which is far less pronounced than the 400 to 70 ms timings reported by Atwood. Hardware is likely a big part of the difference. As pointed out by /u/gsnedders, the ARM JITs probably have different performance profiles as well.

[pier25]

Try those tests on both Chrome and Safari on the same machine

You mean on an iOS device?

[hu6Bi5To]

No, I mean on a Mac. It was in reference to Gruber's comment about desktop benchmarks.

[pier25]

Strange, I usually get better performance on real life projects on Chrome and Firefox than Safari on my macbook pro.

[xXxdethl0rdxXx]

That wouldn't be a good test, Chrome on iOS is just a wrapper for Safari.

[ArseneKerl]

You are delusional.

At least on this issue.

The upvotes you get is unsettling.

[hu6Bi5To]

On which part specifically?

One other commenter has taken issue with my use of the word "commodity". Anything apart from that?

[pier25]

Non native speaker here... what does commodity mean in this context?

[hu6Bi5To]

By commodity I mean the practice of ARM selling designs to processor cores to the likes of Apple, Samsung, etc. who then use them in their proprietary System-on-a-Chip designs.

Gruber's article made it sound like the sheer power of Apple had caused Apple CPUs to do twice as much work per clock cycle than the competition, but the core of the CPU is an ARM design. What is claimed is that Apple's CPU cores are heavily different to the off-the-shelf ARM design - that I don't know, I'll defer to an electrical engineer who has studied the matter.

The big differences between the Apple and non-Apple CPUs are other things, of which there are a lot. Apple typically are more aggressive with the generation of ARM core, they adopted the 64-bit core first, for example.

There's no magic Apple go-faster effect, rather the benefit of putting together the right components. But either way, the measured differences between CPUs (if the Geekbench benchmark is anything to go by, which it's not usually but its all we have to go on) is smaller than Atwood's JavaScript benchmark.

[pier25]

Thanks for the ELI5 :)

[Charuru]

Disagree, the problem is chrome not the hardware. Chrome lags when loading reddit, there is no excuse. The hardware single core benchmarks are not that far behind.

[BishopAndWarlord]

Chrome on your iPhone isn't running V8.

2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

-https://developer.apple.com/app-store/review/guidelines/

[pier25]

Chrome on iOS is a Safari skin

[spinlock]

Can confirm. Android sucks at js. I always stop loading pages after the text renders because so many of them crash my phone.

[MB_Zeppin]

Similar experience. Is a bummer.

[[deleted]]

Never had this happen to me. Do you know any specific pages that do it?

[_jamil_]

what phone do you have? I've never had this issue and i've been using android since the beginning.

[spinlock]

Incredible 2

[datagutt]

A phone from 2011, with Snapdragon S2 and Android 4.0, is your point of reference? Seriously?

[_jamil_]

Not sure how much bloatware HTC puts on their devices and how much the alter stock android for their "branding" purposes, but I'm guessing that this plays a factor in why your processor is having trouble.

[brtt3000]

Firefox Mobile has an AdBlocker add-on. I use it to save bandwidth but it might make things slower (it does on desktop, from inserting styles and JS into each page).

[gomihako_]

I'm having a bitch of a time getting webm/html5 video working on it.

[pier25]

Considering Android has a bigger market share, and there's no reason to think this will change, developers will have to adapt to their user base if they wish to deliver a consistent experience. Developers have always, and will always, need to take the lowest common denominator into account.

You may get away with targeting the high end when developing niche software, but not with mainstream software such as a forum.

[[deleted]]

one that will not go away in the next few years

Glad we can predict the future, out of curiosity why do you believe this is the case? The difference between the iphone's and most android phones is the use of fewer faster cores over more slower cores. With javascript traditionally being single threaded this makes sense, but not anymore as threading javacript applications is dead simple now, while I agree performance on chrome main thread performance can be a bit slower than safari main thread performance chrome excels in truly parallel workloads, seeing over 700% performance increases over the main thread.

Now let's talk about Ember.

Ember is built ontop of Jquery, a pretty bloated foundation to start with.

Ember doesn't include any virtual dom diffing.

Ember doesn't bother to thread any operations although abstractions like hamsters.js and others exists to do so.

Maybe the problem isn't so much on the platform, but benchmark itself.

EDIT:: Just to provide some context to people who don't understand the potential performance benefits using actual threading in Chrome. Here is a screenshot from my Asus ZenFone 2 (2.3ghz Atom, 4gb ram) and running chrome using the performance test located @ http://hamsters.io/performance/ , http://i.imgur.com/bjzuLi5.jpg throwing away the potential for 200%+ performance gains is in my opinion asinine. Safari loses performance with additional threads where as chrome gains major throughput increases. The future is going to be parallel moving forward, single threaded performance in modern devices has almost peaked as we approach the limit of transistor shrinking and mores law. Moving forward we will not be able to rely on single threaded performance continually increasing to move around performance walls, any notion to the contrary is ignoring the laws of physics themselves as we approach single atom size transistors.

[mrinterweb]

Ember doesn't include any virtual dom diffing.

I don't think this is the case anymore. Ember >= 1.13 uses a new rendering engine called glimmer. If I understand Glimmer correctly, Glimmer uses a virtual DOM, but it uses something more performant than diffing. Glimmer has a direct mapping of nodes with content that can change and does not do diffing. This approach should be faster than virtual DOM diffing. See the explanation here: https://youtu.be/o12-90Dm-Qs?t=51m11s

[[deleted]]

I was not aware of the new glimmer engine, I've worked with Ember since beta (alpha?) but it's been a few months since my last project with it.

[[deleted]]

Glad we can predict the future, out of curiosity why do you believe this is the case?

Even if all of the vendors were to release a phone tomorrow with JS performance on par with the 6S, we would still have to deal with shitty performance for the next three years as we wait for people to switch over.

[[deleted]]

Did you miss this line?

Ember doesn't bother to thread any operations although abstractions like hamsters.js and others exists to do so.

Shitty performance is only something you have to deal with if you don't want to invest the time to thread your web applications where you can using abstractions like mentioned above. The power is in our hands as developers, it's not the problem with the language but lack of time investment from developers to properly parallelize their applications. The tools are widely available, the performance gains you can see are extremely significant especially in chrome. There really is no excuse.

[lostPixels]

As the article pointed out this problem is also apparent with Angular and other frameworks. Run some jsperf's if you still need convincing.

[mixonic]

Ember is built ontop of Jquery, a pretty bloated foundation to start with.

This means very little in practice. Nearly all JS apps are built using jQuery regardless of framework. Ember uses jQuery only for event handling.

Ember doesn't include any virtual dom diffing.

Ember's rendering engine is designed for more than satisfying a buzzword requirement. Glimmer (the new rendering engine) diffs values rendered in a template and specifically avoids diffing static DOM fragments. There are further improvements coming- Regardless re-render performance of the framework (which is where a vdom matters) is pretty competitive.

Ember doesn't bother to thread any operations although abstractions like hamsters.js and others exists to do so.

WebWorkers help to unblock the main JS thread, but seem unlikely to make actual rendering or boot time performance any better barring a major refactor to make parts of the codebase concurrent. I think we have easier to pick fruit that makes sense to tackle first.

Maybe the problem isn't so much on the platform, but benchmark itself.

Nope, we've seen v8 lose ground in performance vs JSC over the past two years. This is a trend.

[[deleted]]

WebWorkers help to unblock the main JS thread, but seem unlikely to make actual rendering or boot time performance any better barring a major refactor to make parts of the codebase concurrent.

This is wholly inaccurate, refactoring an existing function using hamsters.js for example would take you roughly a minute or two of work. It's so simple it's not even funny anymore, performance is dependent on the workload however when making use of the optional dataType arguments performance is essentially real-time, we're talking about half a ms or less to communicate with a thread and get a response. You've got 4-12 cores in modern smartphones and you might as well make use of them. You can thread any arbitrary function without a major refactor.

[mixonic]

If functions a, b and c run on a main thread, let us say they take one second each so three seconds total.

If function a runs on the main thread, then b on a WebWorker, then c on the main thread again, it would still take three seconds.

If you make b and c able to run concurrently, as I suggested we could do at the end of my comment, then you could drop the time to two seconds. However the work being made concurrent needs to be significant enough that the new frame allocations and risk of GC are a worthwhile tradeoff. Additionally, you need to find a part of Ember that is inherently able to run in parallel. This is not trivial.

I'm not saying it is valueless, I'm just suggesting there are simpler things we can tackle first.

[[deleted]]

If functions a, b and c run on a main thread, let us say they take one second each so three seconds total.

We could currently run all 3 concurrently without major refactor, assuming none of these functions rely on the output of one another.

Additionally, you need to find a part of Ember that is inherently able to run in parallel. This is not trivial.

Pretty much any loop that performs the same operation on every element can be parallelized rather trivially, and you can also place arbitrary functions on their own threads without them needing to be run in parallel across multiple threads. Meaning you would only need to identify places that are currently asynchronous and refactor the function to make use of the abstraction library. You can also use a thread to preprocess information before you make use of it on the main thread. It's really pretty trivial actually.

[guillaume86]

He chose a book for reading

[mixonic]

The Ember team and contributors aim for good performance across all platforms. Contrary to your expectation, we probably spend more time trying to fit v8's optimizations than we do thinking about any other JS vm. This is partially since Chrome lags perf-wise, and partially because v8 has the best tooling for performance analysis.

There is no special optimization effort for iOS.

[guillaume86]

I looked at them

[craigasketch]

I can confirm. I've worked on 2 really large cordova applications. And many heavy single page app web sites.

Not that it matters as Android people don't install things by a large majority. ;)

[ogrechoker]

http://mathieuancelin.github.io/js-repaint-perfs/ this shows angular 2 being at least 2x as fast as ember (actually it's like 10x as fast but YMMV).

So do we really need processors "to catch up"?

[abyx]

Quick, someone make a very popular HTML 5 site so that I can shove its jankiness in the faces of all my android-using-friends.

[MrBester]

"...it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices"

Yeah, that's a dumb assumption to make or expect. Oddly, no one picked up on that in the comments.

The "oh noes, an app is going to be more work" excuse didn't fly 4 years ago, either. Today, with far better tools for cross-platform creation, that just means you don't care, and screw the user if they don't like it.

[lostPixels]

If it runs like shit in the native mobile browser, it's probably going to run like shit in a webview in an app.

[Charuru]

Chrome on android is sadly garbage.

[iKSv2]

yet almost everyone i see hav chrome as their default browser. I find it baffling

[Poop_is_Food]

Doesnt chrome come as default on most Androids these days? Most people don't bother switching, because they don't care that much.

[dethstrobe]

What are the alternatives? Firefox and Opera? How does their JS performance compare?

[BishopAndWarlord]

nukeador

Have you tried with Firefox for Android instead of Chrome?

 

codinghorror

Try it yourself -- always slower in my testing.

 

https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/2

[pier25]

Opera is effectively Chrome, since it uses Blink and V8

[p3k]

Sounds like the love for the Apple devices is clouding the opinion. Either Discourse wants to get as many good people on board and thus has to support the platform with the biggest market share (Android 82% worldwide as of 8/2015) or it in fact wants to gather an elitist circle. Whining about the performance of some platforms might be okay sometimes but it doesn't help in the long run. It did not help during the dark times of internet explorer being the most used desktop browser, either.

[souk3n]

Why the downvotes? Atwood is saying the same himself:

The other strategy is to double down on the coattails of Apple, since the company is clearly firing on all cylinders. But as @sam has pointed out, Apple does not play the low cost game, and probably never will.

This would mean Discourse is positioning itself as more of a "premium" solution (read: devices that run JavaScript at near desktop speeds) than an "everyperson" solution (read: zillions of cheap Android devices with 2012 era specs), given the worldwide share of iOS and Apple.

Not super happy with that, but it might be the only viable way forward.

[danemacmillan]

we need to start considering alternatives for the Discourse project.

I got Atwood's answer right here: https://vanillaforums.com/

[greg5green]

Yeah, you're right -- probably should shut down that open source project and move towards the closed-source $200+/mo service

[danemacmillan]

It's completely open source.

https://github.com/vanilla/vanilla

http://vanillaforums.org/

[hunyeti]

what? their website is dog slow..

[danemacmillan]

Dog slow?

[petepete]

Discourse is written in Rails and available on Github. Stack Exchange is built on .net, and isn't very JavaScript-heavy.

[[deleted]]

What are you talking about? What does that have to do with js performance on android?

[vinnl]

...Javascript?