

Mobile web apps may be slow because Moore's law is ending - iProject
http://techcrunch.com/2013/07/13/your-app-is-slow-because-our-world-is-ending/

======
cromwellian
The article is right about Javascript, but wrong about why mobile web apps are
slow. Most mobile web apps are not games nor image processing apps, they are
simple content sites or form-driven applications that are not CPU bound and
don't use a lot of JS. These apps are subjectively slower because of browser
layout engine performance.

Even on "heavy" JS apps, I've heard it said they only use 30% CPU. So if 70%
time is not spent in JS, even if you run that 30% 50 times faster, at best you
get a 42% speedup from 50 times better CPU performance.

I feel the author has caused many to have the wrong take-away message, and the
anti-web contingent are lapping it up. Mobile Wep Apps can be made to perform
fast today, but it takes way way too much effort to tweak the CSS/DOM
manipulations to avoid jank. Consider for example the need to manually "hint"
you want GPU compositing by using identity CSS3 transforms.

The rendering engines need to get better with leveraging the GPU and avoiding
work when they don't need to.

If you want to see what a herculean effort can achieve, see Sencha's FastBook.

Basically, the author is right, but I think it's a red herring given that when
people talk about "slow mobile web apps", 99% of the time, they are not
talking about an Instagram written in JS, or AngryBirds in Javascript, but
some basic news feed app.

------
poutine
Even if you accept that giving web apps 10x more CPU than today they'd be
equal to today's native apps (I don't accept this), you must acknowledge
you've given 10x more CPU to the native apps too. And clever people will find
impressive ways to use that CPU in native's advantage (witness all the neat
physics stuff in IOS7).

------
nawitus
>So Moore’s Law might be right after all, but it is right in a way that would
require the entire mobile ecosystem to transition to x86. It’s not entirely
impossible–it’s been done once before. But it was done at a time when yearly
sales were around a million units, and now they are selling 62 million per
quarter. It was done with an off-the-shelf virtualization environment that
could emulate the old architecture at about 60% speed, meanwhile the
performance of today’s hypothetical research virtualization systems for
optimized (O3) ARM code are closer to 27%.

Why do you need virtualization if the code is Java bytecode? Sure, this
doesn't work for iPhone, but Android should be able to easily change the
processor architecture. (If I'm not missing something here). There's already
Android-x86 project.

~~~
brokenparser
Besides ARM and x86, Android also runs on MIPS and PPC.

~~~
jordanthoms
And even for native code, it's generally easy to support multiple
architectures (unless your code is arch-specific).

------
andrewflnr
The original title is more accurate. This edited one doesn't do the piece
justice. He really is talking about the end of an age.

I was expecting some kind of snark, but not this. I'm glad I suffered through
the page crashing my iOS browser once.

------
sixQuarks
Moore's law won't necessarily be progressing in a steady line. We will
probably see more jumps and spikes as technology advances. Do you think
computing power will only merely double once we take advantage of quantum
computing? No, it will go up orders of magnitude in a short period of time.

Our current progression with silicon based computing is slowing because we're
reaching the physical limitations of that technology.

------
nawitus
One additional point is that even if .js doesn't improve much, mobile browsers
can get a lot faster. iPhone's webview is a lot faster than Android's webview,
so there's plenty of progress to be made especially with rendering.

------
williamcotton
Ok dudes, enough is enough.

What actual proof does this dude have that pocket-sized computers have reached
their limits of performance and memory?

All I see are some carefully selected quotes from some "hardware engineers"
who are doing nothing more than offering up their opinion.

An "ex-Intel engineer" and a "robotics engineer" have a single paragraph.
Really, this is your research? Some anonymous quotes, probably taken out of
context?

> I have consulted many such qualified engineers for this article, and they
> have all declined to take the position on record. This suggests to me that
> the position is not any good.

Really.

Do I have to go on?

~~~
anon1385
>What actual proof does this dude have that pocket-sized computers have
reached their limits of performance and memory?

Could you quote the part where the author of this article or the original _Why
mobile web apps are slow_ article say that we have reached a hard "limit of
performance and memory", because I don't see where they say that at all.

The article I'm reading says this:

 _Unchecked exponential growth has to end sometime, by definition, and this is
how it would happen; not with a bang, but with a whimper. We won’t hit a wall,
we’ll just…start…to…slow…down._

~~~
williamcotton
Fine, I concede the point to you, however, I amend my question:

What actual proof does this dude have that performance and memory of pocket-
sized computers have started to slow down?

And how does arguing this point have anything to do with his overall "thesis"?

Forest for the trees, man, forest for the trees...

------
malandrew
Mobile web apps are slow because of layers upon layers of leaky abstractions
and algorithms at each layer that still have a lot of room to be optimized.

If you want a consistent 60 frames a second, you need to architect systems
that complete the work that needs to render each frame within 16.6ms. If you
can't complete all your computations within 16.6ms, you need to prioritize
computations and spread them across frames.

------
ThomPete
It is my experience that the biggest reason for why things are slow is that
they need to fetch content from outside it's environment.

I don't know if this affects JS ability to render it but it is at least my
experience that JS based apps are simply not able to give me the same non-
interupted feel as natively build ones, this includes even apps like RSS
readers.

------
cliveowen
Even if this is true, this only spells the end of exponential growth in
hardware performance and the start of the more efficient software era.
Engineering is all about finding the right compromises to get the job done
given a set of restraints. When the HW performance becomes the major restraint
then you just have to design around that.

------
aswanson
Maybe the slowing of this Law, which I am not convinced of per this article,
will slow new hardware introduction. If this happens, perhaps this will allow
closer optimization of applications to a small, relatively static hardware
complement.

------
unono
Phones should be thin clients anyway, the cloud provides the muscle. What use
is packing compute into it. You just want it get smaller and zero energy use
(using ambient energy for charging).

~~~
mwcampbell
> What use is packing compute into it.

1\. Do computation locally on local data, thus avoiding round-trips to a far
away server.

2\. Distribute an app to lots of people without having to pay for a lot of
server resources to match, since the computation is done on each user's
device.

3\. Enable users to keep more data private, by keeping it on the user's own
device.

------
_random_
I think it's a favour. Coders shouldn't settle for a mediocre language and a
dated platform just because they are ubiquitous.

------
PavlovsCat
_“in a memory constrained environment garbage collection performance degrades
exponentially.” The obvious solution, then, is to throw memory at the problem,
no?_

Isn't the obvious solution to avoid garbage collection whenever possible? Just
consider 'Date.now()' vs 'new Date().getTime()' \- are we even trying?
Shouldn't we start considering unnecessary garbage a bug, like a memory leak?
That might not change everything, but it surely would help, no?

~~~
mherkender
That's an interesting idea, but how does a language distinguish between memory
leaks and regular non-leaks? Maybe some kind of metadata that informs the GC
about how memory will be used so it can optimize memory usage and issue errors
when the code fails to follow these rules?

If we really start hitting these kinds of walls, I think that Javascript
subsets (like asm.js) will become more prominent, but it's an interesting
idea.

~~~
PavlovsCat
Then know that it was your interesting idea, since I wasn't thinking of
anything automatic myself :) Maybe is possible to automate things like
generating code that minimizes branching, or re-uses objects instead of
destroying and allocating them all the time... but it's definitely possible,
in some cases at least, to rethink the approach and reduce GC. Especially
since there are usually trade-offs (using a fixed amount of memory "just in
case" is distasteful for its own reasons), and the programmer might need to
make an informed decision.

But people still need to be aware of it first; making new objects for one time
use is handy, and the normal way to go about things. It's certainly the
default way tutorials tell you to get the time (even in game loops). At least
personally, before today I didn't even know about Date.now(), and I never saw
a discussion about any of this stuff in regards to libraries (how good or
sloppy they are with GC)... it just doesn't seem to be on the radar, outside
of gamedev. And by the time stuff gets sluggish by the accumulated little
objects here and there, there is no easy fix, other than a whole lot
refactoring or rewriting from scratch with it in mind.

------
andyl
Performance anxiety for a whole class of devices that DIDN'T EVEN EXIST a few
years ago, enabling GIANT NEW MARKETS.

'Our world is coming to an end.' Gotta love it.

------
mtgx
I think we have another 10 years or so until 2-3nm chips.

