5 ms·

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance bet

The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.

dahdum 11y ago
I think that's the key, from the Atwood article: "In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing."
exelius 11y ago
It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manufacturers bundle their own browser that it will be a long time before those users with "old, slow" JS on Android go away. I don't know how the JS engine is bundled on Android, but if it's bundled with the core OS then the vast majority of phones would just never get updated. Developers have to deal with that, so unless you're ok with excluding a large percentage of mobile devices on the street, dealing with slow JS performance is simply a fact of life on mobile.
- nostrademons 11y ago
  It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it before execution can even begin. 2. The native Android GUI frameworks render views on the GPU. Chromium will only render views on the GPU if you have a CSS transform or opacity property set. If you're not very careful, you can easily trigger an expensive layout + repaint calculation on every frame. It's possible to write webapps that perform just as well as native, with fancy animations and fluid user experiences. I had some existence prototypes when I was still at Google, and some of the research for that went into the current Google Search app experience on Lollipop. But it was a huge pain as far as the developer experience went, and a lot gets lost in translation when productionizing. It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window.
  - mwcampbell 11y ago
    Why doesn't Chromium render more elements on the GPU?
    - nostrademons 11y ago
      They had (have?) a project to do that: https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome https://www.chromium.org/developers/design-documents/gpu-acc... http://www.androidpolice.com/2014/11/19/project-ganesh-demoed-at-chrome-dev-summit-makes-chromes-page-rendering-a-lot-faster-by-working-directly-on-the-gpu/ http://www.androidpolice.com/2014/11/19/project-ganesh-demoe... I don't know what the status is of it. It'll help paint times (probably significantly), but it can't do much for layout, because the way the CSS spec is written, certain CSS properties require global calculations to figure out where every box should be laid out. (Think about floats, where they're supposed to butt up against other floated boxes, even if they don't have the same parent.)
    - exelius 11y ago
      Because rendering on the GPU isn't a panacea. On mobile platforms, it can have negative implications on battery life and performance, and given the sequential-dependent nature of CSS rendering, I'm not sure you'd even get the benefit of parallelization. In many cases, you'd end up waiting for the main thread most of the time anyway (which you'd probably also get if you just spawned a few threads on another CPU core). It also adds a hell of a lot of complexity since SOCs have varying levels of capability in their GPUs, which your code now needs to identify, integrate and test against. I'm not claiming there's no benefit, but there's a reason they don't just GPU all the things.
  - brlewis 11y ago
    When browsers support stale-while-revalidate we'll have the opportunity to make web apps update in the background the way native apps do. Weight still matters; I just thought this worth mention.
  - exelius 11y ago
    JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly pushing the envelope on single-threaded performance. And let me be clear: JS being single-threaded isn't a bad thing in itself (the thought of a multi-threaded language in the browser gives me nightmares). It just makes the user experience of JS suck on mobile. And that's not going to change any time soon given the glacial pace of patch/update deployment on Android. > It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window. That approach -- while interesting from a technical standpoint -- kind of defeats the purpose of a browser :) I mean, you're basically building another browser inside the OpenGL window...
thomasahle 11y ago
I don't quite get the Atwood article, in both of the benchmarks he shows, Kraken and Octane, the Android device scores better than any IOs device, when using the stock browser. It's only when using TMOUS they do worse, so why do anybody use that?
- Roboprog 11y ago
  TMOUS = T-Mobile??? Or something else?

dahdum 11y ago

I think that's the key, from the Atwood article: "In a nutshell, the fastest known Android device available today -- and there are millions of Android devices much slower than that out there -- performs 5× slower than a new iPhone 6s, and a little worse than a 2012 era iPhone 5 in Ember. How depressing."

exelius 11y ago

It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manufacturers bundle their own browser that it will be a long time before those users with "old, slow" JS on Android go away. I don't know how the JS engine is bundled on Android, but if it's bundled with the core OS then the vast majority of phones would just never get updated. Developers have to deal with that, so unless you're ok with excluding a large percentage of mobile devices on the street, dealing with slow JS performance is simply a fact of life on mobile.

nostrademons 11y ago
It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it before execution can even begin. 2. The native Android GUI frameworks render views on the GPU. Chromium will only render views on the GPU if you have a CSS transform or opacity property set. If you're not very careful, you can easily trigger an expensive layout + repaint calculation on every frame. It's possible to write webapps that perform just as well as native, with fancy animations and fluid user experiences. I had some existence prototypes when I was still at Google, and some of the research for that went into the current Google Search app experience on Lollipop. But it was a huge pain as far as the developer experience went, and a lot gets lost in translation when productionizing. It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window.
- mwcampbell 11y ago
  Why doesn't Chromium render more elements on the GPU?
  - nostrademons 11y ago
    They had (have?) a project to do that: https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome https://www.chromium.org/developers/design-documents/gpu-acc... http://www.androidpolice.com/2014/11/19/project-ganesh-demoed-at-chrome-dev-summit-makes-chromes-page-rendering-a-lot-faster-by-working-directly-on-the-gpu/ http://www.androidpolice.com/2014/11/19/project-ganesh-demoe... I don't know what the status is of it. It'll help paint times (probably significantly), but it can't do much for layout, because the way the CSS spec is written, certain CSS properties require global calculations to figure out where every box should be laid out. (Think about floats, where they're supposed to butt up against other floated boxes, even if they don't have the same parent.)
  - exelius 11y ago
    Because rendering on the GPU isn't a panacea. On mobile platforms, it can have negative implications on battery life and performance, and given the sequential-dependent nature of CSS rendering, I'm not sure you'd even get the benefit of parallelization. In many cases, you'd end up waiting for the main thread most of the time anyway (which you'd probably also get if you just spawned a few threads on another CPU core). It also adds a hell of a lot of complexity since SOCs have varying levels of capability in their GPUs, which your code now needs to identify, integrate and test against. I'm not claiming there's no benefit, but there's a reason they don't just GPU all the things.
- brlewis 11y ago
  When browsers support stale-while-revalidate we'll have the opportunity to make web apps update in the background the way native apps do. Weight still matters; I just thought this worth mention.
- exelius 11y ago
  JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly pushing the envelope on single-threaded performance. And let me be clear: JS being single-threaded isn't a bad thing in itself (the thought of a multi-threaded language in the browser gives me nightmares). It just makes the user experience of JS suck on mobile. And that's not going to change any time soon given the glacial pace of patch/update deployment on Android. > It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window. That approach -- while interesting from a technical standpoint -- kind of defeats the purpose of a browser :) I mean, you're basically building another browser inside the OpenGL window...

thomasahle 11y ago

I don't quite get the Atwood article, in both of the benchmarks he shows, Kraken and Octane, the Android device scores better than any IOs device, when using the stock browser. It's only when using TMOUS they do worse, so why do anybody use that?

Roboprog 11y ago
TMOUS = T-Mobile??? Or something else?