It's not that "native software" has become less efficient, but rather that it is slowly disappearing.
how fast JS engines have become in the browser
Maybe it is about emulation the whole system but still I was expecting better.
Is there anyway I can find out the call flow of this JS program?
Like to see the actual dynamic call flow graph instead of just simple static flow analysis output.
Your phone is doing all sorts of weird shit behind your back as you poke about. Stuff that it's not supposed to be doing if app-makers were actually respectful of their users...
On that note, why does that crap take so long on smartphones anyway?
Another thing is that Windows would put certain native widgets (like file selection) on a higher priority than other program code. Android, at least, tries to put as much stuff in userspace as possible, so you might be experiencing the reality if everything run at the same priority.
That's very subjective, I'm in a minimalist passeist phase.
[1] Except for the non isolated driver model.
> ...one to one with that simple machine.
Recommendation: Forth (cf. colorForth)
Warning: Save snapshot of current mental state/perspective/worldview first, to guarantee sustained mental health :P
I occasionally do too :P
> Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it.
I know the feeling... but I'm still at the "Lisp looks like parenthetical line noise, and what even is* ML?" stage, so I haven't yet tackled those.
Forth, to me, seems to be bring out the "mechanicalness" of the computer, in a weird sort of way. Of course it's just another programming language, but the philosophy and mentality behind it seems to lean in that direction. I like it for that, and its minimalism. :D
I kinda understand the mechanicalness of Forth, if you mean that there's only a few principles and that even 'syntax' is built on that. The kind of less is more that frees your mind
Meanwhile, on actual mobile hardware, the performance is so atrocious it's completely unusable.
No knock on the implementors of course. But the idea that this demo has some deep insight about the performance of native smartphone software is just inaccurate.
In general there's an arms race between hardware getting faster and native developers getting more and more lazy about efficiency. On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.
It is easy to take potshots at e.g. iTunes, but the real reason software "got worse" is not developers getting lazy. What happened is that expectations for CPU-intensive features rose (memory protection, ASLR, NX, encryption, low-latency audio, high-efficiency codecs, ClearType) while willingness to pay vanished. In Win98 times, you bought your music player from the developer (remember Winamp?) whereas now it comes free with your OS, which is itself probably free. So of course it is all half-assed now, but it's not "lazy" to spend resources on software someone will pay for, and not on software nobody will pay for.
You could absolutely reverse this, but it has nothing to do with native or web technology, and everything to do with changing consumer attitudes about choosing software.
> On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.
From 1995 until today, power consumption in desktop processors grew about 5-15x, depending on how exactly you measure. 5-15x more power on mobile devices is simply not an option, unless we have a "new physics" kind of breakthrough in both battery and thermal technology.