Multiple cores and and especially the big/ little core design seems to be more energie efficient.
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.
See also React.js Conf 2015 - Hype!
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 2935 - Poor performance in Ember app Discourse - v8 - Monorail 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, The Mobile CPU Core-Count Debate: Analyzing The Real World
was the article I had originally in mind.
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.
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:
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.
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.
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?
Indeed. One example is Gazelle:
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
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 | '---------------------------------------------------------'
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.