With regards to single core performance, http://www.androidauthority.com/fact-or-fiction-android-apps-only-use-one-cpu-core-610352/ (ok it’s an android “fanboy”) suggests, that todays mobile browser can use multiple threads. So your assumption is that your javascript can only be executed in single thread and is also the bottleneck?
Multiple cores and and especially the big/ little core design seems to be more energie efficient.
Javascript is not a multi-threaded language. All of the code on a single page must be executed on one core, it cannot be spread across cores (although it can move to a different core). The browser can use other cores for HTML/CSS/etc. rendering, image rendering, and other tasks, but it can’t use multiple cores for the JS code on a single page.
6 Likes
This is an interesting thread, and I have a few thoughts considering the future of JS app performance on Android.
I don’t think switching frameworks is practical. Ember was chosen because of the community’s maturity and the maintainability of its applications. Porting a codebase this large is unfeasible.
Although devices may not satisfy hardware requirements, we can trust that mobile browsers stay auto-updated with the latest features. Browsers that make up 97% of usage are close to the latest version of that browser.
Therefore, progressive enhancement that targets the latest browser features is a smart way to ensure performance improvements. (e.g. Web Workers, Service Worker, HTTP/2, etc…)
If a browser supports Web Workers, initialize a couple on first load and offload JSON parsing or AJAX requests to them.
Default to HTTP/2 for faster download of assets. Fallback to HTTP/1.1 if a browser doesn’t support it.
Since requests are cheap, HTTP/2 makes bundling an anti-pattern. This will let you prioritize requests, while giving you fine-grained control over cache. Use Service Worker to offline large parts of your app.
I have a feeling that HTTP/2 would give a dramatic increase page load performance.
3 Likes
Sure, usually the Java script code execution is not really multithreaded, also there are Web workers, which can use all CPU cores, see http://stackoverflow.com/questions/11871452/can-web-workers-utilize-100-of-a-multi-core-cpu.
Still the question is why Ember is bottlenecked by Javascript single thread performance, whereas for other frameworks that does not seem to be the case, which would lead me to the conclusion that today ember might not be a good choice for mobile web applications. Single thread performance is not going to increase for a long time anymore on mobile, whereas multithreaded performance will continue to increase for a much longer time.
See also YouTube
Ok biased again, but still …
Same exact performance issue with Angular, confirmed by a Google employee, in writing, in their bug tracker. Please read the entire topic before replying.
Also, single thread performance has increased dramatically on mobile over the last four years. Feel free to scroll up and read where this was cited, with data and graphs, several times…
you mean https://code.google.com/p/v8/issues/detail?id=2935 I guess, Sorry must have missed this in this long thread.
Sure that does look like a bug/limitation in V8. That is sad, but better single thread performance would only be a workaround, because it is only hiding the cost of the deops. And as we all know single thread performance is not going to improve for a long time, so relying on it is problematic.
BTW I guess the Intel based Android devices should be faster then, mostly tablets and the market share is probably minor, because the usually had good single thread performance in benchmarks.
An idea: Make the Discourse API a first-class citizen.
I’m specifically thinking of a professional micro-site and API endpoints which target Android developers: Key creation specific to client-side apps, true sample mobile Java code, etc. For example:
BTW with regards to multicore versus single thread performance, http://www.anandtech.com/show/9518/the-mobile-cpu-corecount-debate
was the article I had originally in mind.
1 Like
Then we could bet that iOS will kill Android in the following 10 years. 
It is to an extent not such a problem because everyone else is in the same boat.
If Discourse runs faster than Facebook on the same Android device, the actual timings are irrelevant as the user is used to and expects the lag.
Android speeds are only going to increase and they are usable at the moment.
Just don’t look at your friend’s Apple and there’s no problem.
1 Like
I don’t think Angular is a good example of a performant framework, it’s fallen way behind some of the newer frameworks. Angular 2.0 has massively improved performance mind you. Here’s a good benchmark that pushes the DOM in terms of raw updates per second:
1 Like
You’ve mentioned something like this in a few replies. Do you have an idea of how you would detect “ancient devices” or subpar performance? Seems like a tricky thing to detect / progressively enhance on top of.
True, if it is an ancient device running a current copy of Chrome for Android for instance. We already detect Android and send down half the data we send for iOS – so there is a way, and it is reliable. 
1 Like
Seems to me it’s an opportunity, albeit a forced one, to rethink what discourse needs to be on mobile devices. That’s not necessarily a bad thing.
If we were just talking about old devices with poor performance it would be difficult to justify a rethink, but since it’s new devices, and so many devices, it seems like a relatively easy thing to justify. The steps you take to accommodate slower JS performance on Android today will benefit not just today’s Android devices, but older devices, and also new underpowered mobile devices that will be driving the growth of the web, for years to come (as a billion new people find their way online).
You could really see this as the right problem to have at the right time.
1 Like
Is there a company that makes buying an older iPhone as easy as certain 3rd party companies used to make buying a used Mac? Perhaps an opportunity here?
I would not buy anything earlier than the iPhone 5 though. 5s would be my budget recommendation.
I am trying out meta on the doogee x5, a 80usd android phone, topic page is a bit sluggish, but front page is quite good due to my optimisations a while back, composer is functional albeit sluggish
Biggest pain points are initial load and topic page
We have ongoing plans to improve both
- I reduced initial payload size yesterday by stopping rendering of no script on mobile
- @eviltrout is looking at splitting the initial js payload a bit so composer is only loaded as needed
- We are investigating virtual dom based components which will make the topic page very much faster
- Composer is sluggish to react when typing going to look at that one now
13 Likes
I’m now getting ~250ms on the 1.11.3 complex list test w/ Chrome 46 + Nexus 9 (Marshmallow)
Ember Version: 1.11.3
User Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 9 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Safari/537.36
.---------------------------------------------------------.
| Ember Performance Suite - Results |
|---------------------------------------------------------|
| Name | Speed | Error | Samples | Mean |
|---------------------|-------|--------|---------|--------|
| Render Complex List | 4.12 | 883.19 | 52 | 242.81 |
'---------------------------------------------------------'
Baby steps!
3 Likes
Interesting, the Nexus 6p gets 280ms on Chrome latest (stable), so that’s a minor improvement as well and it appears to be Marshmallow (Android 6) related.
1 Like