https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889 codinghorror Jeff Atwood co-founder For several years now we've tracked the fact that, over time from 2012 onward, Android JavaScript performance has become wildly divergent from iOS JavaScript performance. And not in a good way. To give you an idea of how divergent it has become, try: http://emberperf.eviltrout.com Complex list Ember 1.11 This is the benchmark most representative of Discourse performance, and the absolute best known Android score for this benchmark is right at ~400ms on a Samsung Galaxy S6. That doesn't seem too bad until you compare.. iPhone 5 → 340ms iPhone 5s → 175ms iPhone 6 → 140ms iPad Air 2 → 120ms iPhone 6s → 60-70ms 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. We've done enough research to know this issue is not really specific to Ember, but also affects Angular andmost other heavy/complex JavaScript on Android. Why? Part of it is indeed Chrome/V8 JavaScript optimization issues on Android as you can see from this AnandTech Galaxy S6 review. Note the browser used: It's also partly because single core performance on Android is falling way, way behind iOS. Notice that the flagship Android device barely has the single core grunt of an old iPad Mini based on the old A7 core. Compare single core Android GeekBench versus single core iOS GeekBench: It seems the Android manufacturers are more interested in slapping n slow CPU cores on a die than they are in producing very fast CPU cores. And this is quite punishing when it comes to JavaScript. This is becoming more and more of a systemic problem in the Android ecosystem, one that will not go away in the next few years, and it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices. That is clearly happening on iOS but it is quite disastrously the opposite on Android. I am no longer optimistic this will change in the next two years, and there are untold millions of slow Android devices out there, so we need to start considering alternatives for the Discourse project.
Damn, love my HTC but hate that my wife's Iphone 6 is faster and gets better service on the same carrier.
This is an interesting read, but to be fair, the biggest things in ES6 seem to be workers, generators and promises which really shows you that the Javascript world at large (not just mobile, but also desktop and server) is really trying to move away from single-core computing to concurrent computing. I am going to say that it seems to me that this is much less of an issue than he is trying to make it to be. I know that we use clusters in our node server code to take advantage of multiple cores, we use workers on our client code anytime there are long computations that you need to perform at the JS level - who really needs to perform such massive computations on the client in single-threads anyway? Advanced graphics is mostly going to the GPUs that are massively parallel anyway, workers should be able to break whatever large jobs you have into multiple threads - but quite often, when you really need to do these large computations you just throw things to the cloud and run them on much faster servers anyway. It is not like you have giant databases locally on the mobile device that require that much speed in single core execution. What applications are really needed on mobile that require desktop level single-core performance? Do not get me wrong - I think it is super-impressive how fast the iPhone 6S is even compared to the iPhone 6 - these guys are doing amazing job with their CPU design - but I am just not sure that single-core Javascript performance is that big of a deal in the mobile world.
I don't think you can excuse away Android's poor JavaScript performance. That post is by one of the foremost JavaScript experts. JavaScript is single threaded, and there is not anywhere enough in terms of applications that use worker threads and the like. People do things like filter/map/reduce in JavaScript on arrays of items (like forum threads) that do take time to execute and compose in JavaScript. Anyone who uses a JavaScript heavy application, including using any of the popular frameworks (AngularJS, React, etc.) is going to suffer poorer user experience due to the JS engine performance. The issue isn't massive computation or rendering, it's simply using jQuery to select a bunch of elements by selector and adding a class to them - the JavaScript performance matters a LOT.
Javascript in it's ES5 incarnation (came out in 2009) is single threaded, but as I pointed out - ES6 (the new generation of Javascript that the spec just released in June 2015) is heavily into multi-threading via workers, promises and generators. Javascript, as a language, seems to bet big on multi-core support. All new Javascript engines are slowly getting more and more ES6 features. This is the new Javascript. This is where the world of Javascript seems to be going. You will see more and more engines support it and more and more libraries updated to take advantage of it. Honestly - we write a lot of Javascript. Using jQuery or whatever library you want to query a large DOM structure and add a class to it is a milliseconds operation - no-one is going to see the difference between a 20ms or 80ms operation. There is no reasonable difference between these. Our KendoUI app UI is just as snappy on my old Nexus 7 from 2013 (which is really slow compared to modern phones) as it is on an iPhone 6 - I am certain it runs a lot faster on the iPhone 6 - you just can not feel it, this is not large enough a dataset for the single-thread performance to really see a difference. There is one forum that does not support Tapatalk that I read with that same Nexus 7 directly - and it is super-fast (actually much faster than Tapatalk, I should really check S2 directly in the browser there as well) - the computation speeds are fast enough for these operations for user perception. I do have a side-project that does Non-Photo-Realistic rendering in Javascript where I have really large datasets and the code does not fall into the normal GPU processing patterns for graphic programming - that is where you can see how slow single-core JS is on my old Nexus 7. But, if I break my dataset to run on 3 concurrent workers (with one core for the master) - it is a reasonable wait time for a complicated, cpu heavy operation. Granted, it is faster on the iPhone 6 (and should be even more so on the iPhone 6S) - but my Nexus 7 is 3 generation old as far as a CPU is and runs 32 bit. I am certain that if were to run this code on an Octa-core 64bit processor like the latest Samsung device (I can't stand Samsung's WizTouch so I will not purchase one, but this is a different discussion) - it will be just as fast if not faster than the code on the iPhone. With that said - what Apple has done is basically made it much easier to write good performing JS code on their processor - and that's very impressive and very smart - you have to work hard to write bad performing Javascript software on the Apple, where it is much easier to write bad performance JS software on devices that are not optimized for single-core performance. It is always easier to write simple, single-threaded code and have it run fast. It is just that I am not certain how much of an issue it really is in the mobile world - because I still do not think that there is really that much need / real-world application for desktop class single-core javascript applications on mobile devices.
I write ES5 and ES6 all day for my living. JavaScript is single threaded. People absolutely notice the slow performance. You are arguing against Jeff Atwood, who founded Stack Overflow, Stack Exchange, and WikiPedia. I know he's right.
BTW, I visit S2 on my Galaxy Tab 4, and when I click on a link to view a thread, the screen goes blank for seconds and then the whole page appears. It's really slow.
I just moved to my old nexus 7 and writing from it, it is all snappy and good. This could very much be an issue with the Samsung.
I write Javascript for a living too - and honestly, most of my work is not single-threaded anymore. Maybe because I did so much work on Node where everything is async - but we use promises, clusters, workers - everything to run things concurrently all the time. I am also not arguing that Javascript single-core is not slower on Android devices - it is - what I do argue is that I am yet to hear of a real-world application where it is really that important. S2 is fast and responsive on my antique Android device. DOM manipulation needs to be really stupid to be slow on it - it is really not an issue I can feel with S2, our own software or other things I do in the browser. Jakob Nielsen in "usability engineering" has 3 "classes" for perceived performance - anything less than 0.1 second (100ms) feels feel instantaneous, anything up to 1 second is generally OK, but the user will feel the pause and finally, if an operation takes 10 seconds or more to complete, you’ll struggle to maintain the user’s attention. I just ran an interesting test, on that Nexus 7 I cleared the cache - and over my 801n wifi connection went to CNN.com - a heavy web page with a lot of images, it took from scratch until it finished 2.5 seconds and that included all the network communication - which you know is likely to be an order of magnitude larger than whatever CPU is needed to make it nice and responsive. I ran the exact same scenario on my desktop with the Chrome Dev Tools - it was almost 2 seconds of network (and this machine is not on wifi - so likely faster). This leads me to believe that the Javascript on this page is well below the 1 second portion of the performance - quite frankly, someone has to write really bad DOM manipulation for it to be a real issue in most applications. I was answering specifically about S2 on the Samsung. The Nexus 7 is running Lollipop with the latest Chrome build - and S2 is snappy on it. Again, not arguing that Javascript single-core performance is great on Android, it is clearly not, the benchmarks show it so. I just do not think it is that much of an issue in the real world.
Ha! Funny to see that said. On the other side of the issue, people do not notice faster performance, if it was already fast enough for people not to perceive a delay. Come to think of it, slower is ok too if it is still fast enough.
In a company of 50+ JavaScript developers, nobody here wants to work on android because it sucks. Read carefully. 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. We've done enough research to know this issue is not really specific to Ember, but also affects Angular andmost other heavy/complex JavaScript on Android. Why? Part of it is indeed Chrome/V8 JavaScript optimization issues on Android AND This is becoming more and more of a systemic problem in the Android ecosystem, one that will not go away in the next few years, and it may affect the future of Discourse, since we bet heavily on near-desktop JavaScript performance on mobile devices. That is clearly happening on iOS but it is quite disastrously the opposite on Android.
Another post by Atwood from 2014. > 1 second and closer to 1.5-2 seconds for Galaxy and Nexus devices. Measured not by the sphincter test, but accurately in milliseconds. We're not talking your 100ms perception kinds of values here. http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-android/6577 One thing we have struggled with for a year at Discourse is how slow Ember is on Android devices. How slow? See for yourself: Ember 1.8, Complex List test: http://samsaffron.github.io/ember-performance/?ember=1.8.0672 iPad Air 2 -- 224 ms iPhone 6+ -- 252 ms iPhone 5s -- 300 ms iPhone 5 -- 600 ms iPhone 4 -- 2031 ms Galaxy S5 -- 1297 ms Nexus 5 -- 1426 ms Nexus 7 -- 1930 ms Surface Pro 3 Core i5 IE 11 (x64, touch) -- 613 ms Firefox latest -- 312 ms Chrome latest -- 260 ms Desktop Core i7-4470k IE 11 x32 -- 390 ms Firefox -- 245 ms Chrome -- 181 ms Intel Bay Trail Atom Asus T100 1.33 Ghz Z3740 IE 11 (x64, touch) -- 2.2 sec Firefox latest -- 1.6 sec Chrome latest -- 1.2 sec There is a year old bug open in Android Chromium on this.. https://code.google.com/p/v8/issues/detail?id=2935333 I had some hope that Android 5 / L would fix this somehow as the old creaky Dalvik was replaced with native code. But people have replied with preliminary Lollipop results and they look no better, so I am no longer optimistic. I do have a Nexus 9 ordered, which is as good as it gets for the forseeable future, and I will report in when that arrives. It's been a year now since we originally observed the problem. Ember performance is great on iOS and laptop and desktop, and improves every year as hardware gets faster... but horrendously bad 3x - 5x slower Ember Android performance, for better or worse, seems to be the long term status quo. Is there anything Ember can do to help address it? Either by nudging people at Google or identifying exactly why the very same Javascript is so incredibly slow on every Android device?
Apple is kicking android's ass lately. http://bgr.com/2015/05/18/iphone-6-vs-samsung-android-sales/ Samsung’s iPhone nightmare is far from over, and now it’s affecting Google and http://bgr.com/2015/01/29/tim-cook-iphone-6-vs-android/ You might think of iPhone owners as an insular crowd, constantly upgrading from one device to the next, year after year, but Tim Cook says that’s not the case. In an interview with The Wall Street Journal, Cook said that fewer than 15% of iPhone 6 and 6 Plus sales came from customers upgrading from another iPhone. (which means they're upgrading from android phones)
I'm pretty sure everyone who upgraded from an iPhone 4 to an iPhone 5 noticed how much faster everything worked. I'm pretty sure everyone who upgraded to the iPhone 6 also notices the speed increase. Hard disk is plenty fast. Next to an SSD, it's dog slow.
Loved everything about Portland other than the weather, but I can not see myself coming back - as much as I loved everything else there - we are just loving it down in the San Diego area. There are things that are not as nice as Portland and it was hard to leave friends behind - but honestly, I think that I enjoy San Diego more. Portland will always have a special place in my heart - and I am ready to come back for a visit - but that's about as much as I can take the rain.
Lol why is everyone still having a Samsung vs iPhone debate? Hint. They both suck after. A couple years. My wife has stuck with iPhones and I've always been android so I've been able to see both sides of the table. Honestly I stay away from Samsung and apple. Give me a nexus stock android any day of the week over a Samsung. Tbh the rumored HTC one m10 is going to destroy apple and Samsung spec wise. That's the one I'll be waiting for.
