I’m not sure what speed my Galaxay S4 gets, but I honestly hardly notice any real slowness, sure the initial load isn’t instant, but it is like I have to set my phone down and wait either. If you go the route of defining “older mobiles as non-js”, I would like a way to force it into JS mode, as most of the time, I visit via mobile out of necessity, not desire, and part of the necessity is being able to reply or act on a give topic/post.
Isn’t a JS website app also a “lower common denominator solution” when compared to native apps?
If the issue is that android devices improvement focus on multithreading, using web workers could help.
me? ipad air 1 as stated above.
[quote=“sam, post:68, topic:33889”]
Try latest, or meta, I worked around a horrible bug 2 days ago
[/quote] it’s still weird on the ipad.
I can select, but the iOS menu “copy/select/…” pops up above/on top of the quote reply button.
Quote reply button appearing above iOS menu
Point of clarification: we know the performance gap comes down to the software, not the hardware. Chrome on desktop is much slower than Safari on desktop, on the same hardware. (People just care less about the gap on desktop, because both are “fast enough”.)
After much deep-diving into V8 internals, I am convinced it is because V8’s optimizing JIT compiler is way too aggressive. It constantly attempts optimizations that turn out to be bad and need to be backed out. Basically, V8 gambles hard on optimizations: if they turn out to be right, it is blazingly fast. If they turn out to be wrong, it’s worse than not trying to optimize at all.
This is why you will often see “(compiled code)” as the number 1 thing getting garbage collected in an Ember app on Chrome. V8 is constantly compiling functions, discovering they are overspecialized, and throwing them away.
You are actually describing a Microsoft tactic. As far as the user is concerned, the site IS at fault. It’s just that some of us know it’s an Android hardware deficiency. Let’s not tell them, since then they would only go to iOS like everyone else with a clue in this game. Once they get in iOS and realize all the lies they’ve been told about it are wrong, they will be just like a Mac user moving from Windows–they will NEVER give up the Apple gear. LOL
@codinghorror What browsers did you run the benchmarks for the Apple devices on? I’m on a iPhone 6 Plus and I can’t run the benchmarks on safari. It just won’t start. On chrome 45, I got the following results:
My first attempt was using emberjs, and this was ridiculously slow. Weak spots I could find:
- using dirty checks instead of object.observe. This makes ember’s store really slow.
- using css classes is slow, especially used at top-level
- jquery events on a too broad scope
- other things I can’t remember now, it’s in my todo list of stuff to document
Then I migrated to aurelia.io which uses latest chrome capabilities, and a lot of custom code to allow fast repaint ( object.observe, canvas, webworkers, directly handle events myself instead of wrapping it with jquery, etc. ), and then I could get something that can be used for the purpose of realtime control.
So, it’s hard choices, I’m not in your shoes, but I’m pretty sure a dedicated android application is not the best investment, and that you should try harder to either fix or start from scratch the web application with a better foundation.
ember doesn’t seem load in safari - i had the same problem.
I guess my question is: how big of a deal is this to actual Android users?
You’re comparing raw iOS numbers to Android numbers, and sure, they can be a little jarring.
But Android users aren’t sitting there holding an iPhone in one hand and their own phone in another. In other words, instead of comparing Android numbers to iOS numbers, maybe try comparing “Discourse on Android” numbers to “Other sites on Android” numbers. And not just numbers, but usability, etc.
I have a Galaxy Nexus, and only-okay internet usage comes with the territory of having an old device. Most websites are pretty slow. But I don’t also have an iPhone, so in a way I don’t know any better.
Discourse might be 5 times slower on Android compared to iOS, but it’s about the same speed (?) as other websites on the same device, and I think that’s the comparison most people actually care about. Apples and oranges, and all that.
I won’t say you’re making a mountain out of a molehill, but I do think maybe the people who live on the mountain don’t really mind that it takes them a little longer to get to the nearest Chipotle. Instead of worrying that people in the city can get to a Chipotle in 10 minutes instead of the hour it takes the mountain people, compare the time it takes the mountain people to get to the nearest McDonalds, because that’s the only comparison that matters to the mountain people.
Android users as mountain folk and Discourse as a Chipotle. I think that metaphor got away from me.
Edit: Whoops, I guess this is pretty much what @benfreke said. So, uh, what he said.
Just scored 236ms on my Note 5 using Next Browser. Looks like hardware isn’t the most important factor here.
Qualcomm Snapdragon series, Samsung Exynos series, I suppose Nvidia Tegra and standard ARM for the companies without an architecture license. That’s not that many, unless I misunderstood or I’m missing something. I just don’t think Google is trying all that hard to get Chrome high and tight. They seem to be depending on yearly faster hardware covering up the issues until they are fast enough for people to not complain.
with configurations i was referring to the fact that apple has a7,a7x a8,a8x i think and a few combinations with an extra core. But their designs are VERY homogeneous .
The situation with android (cpus):
They vary from 1 to 8 cores. Some designs are 2 big 2 small, some are 4 big, some are 4 small (ish).
That’s spanning several archictetures and bit sizes. They presumably require different optimizations - and google will have a hell of a hard time optimizing for all of them.
That’s not even getting into screen sizes, ram amount, storage speeds etc…
There are Several orders of magnitude more android configurations than there are iOS configurations.
I wonder what the benchmark looks like running in Intel’s Crosswalk. When I was attempting to deploy IonicFramework apps, it greatly improved the performance and consistency of our app. It made scrolling almost bearable.
That’s a bit of backwards reasoning. With slow cores, and numerous ones, vs few high performing cores, you expect the same performance. Numerous slow cores will always be slower here. Just the work to switch from core to core, the way these processors are designed, wastes too many cycles.
Then there is the problem of four faster, more sophisticated cores, with four slower, less sophisticated cores. The processors were not designed for all of them to be working on the same problem at once. It’s a fundamental error in usage.
It is a combination of software and hardware. Based on the geekbench score, a galaxy s6 should be able to do close to as well as an iPhone 5s which has very similar geekbench single core score. You can see this in the AnandTech results I screenshotted when comparing the native browser and Chrome.
@tgxworld the benchmark runs fine in my very stock iPhone 6s under Mobile Safari. Maybe hard refresh?