> the bogus "optimizing is evil" knuth quote.

Read the quote again - Knuth talks about "PREMATURE optimization"! (it is a common mistake to leave the word out - but it alters the meaning significantly).

You should optimize only when you know what should be optimized (and how), which is very true for all platforms alike. And it is just common sense if you think about it.

Why is this quote important? Because most "not so good" programmers spend hours and hours polishing things that are not important (see StackOverflow for huge number of examples) but they feel ( / know / sense /...) will make for a better performance. On the other hand they often sacrifice code legibility, correctness and even the real performance in the process.

Not bogus at all.

Yes, we desperately need the "mobile is the new desktop computer" meme to die. You get what you pay for, and a CPU that barely consumes a watt will not deliver desktop performance, no matter the cores, memory or frequency.

That said, compared to actual CPU- and memory-starved embedded systems, mobile is a freaking race car. If you measure your memory in multiples of megabyte, you need not apply. Given that, the performance situation on mobile is rather appalling.

> That said, compared to actual CPU- and memory-starved embedded systems, mobile is a freaking race car. If you measure your memory in multiples of megabyte, you need not apply. Given that, the performance situation on mobile is rather appalling.

YES! Maybe it's my use of the word "computer" above? I didn't want to imply one should expect the same performance from a mobile phone that they expect from a desktop. I called it a computer because it computes, not because it qualifies for being put in a big case with keyboard in front of it.

> Those CPU don't have as much cache memory (which is vital for a CPU to be fast), are very low powered, and not cooled by any fan.

They are, nonetheless, far more powerful than computers which ten years ago ran comparable applications of comparable feature and comparable eye candy complexity (if somewhat lacking in design taste).

I think cache memory should mostly be irrelevant for many of the user-facing mobile applications. They tend to be more I/O bound than computationally-bound. I think something is seriously fucked up if a programmer manages to screw up the performance of his Twitter client or chat application because of caching. This isn't the case for, say, mobile games or various types of multimedia applications, but that's a different story. The point is, a native-looking interface made up of nothing but native-looking widgets has no excuse for being laggy on such a platform.

Cache memory is not vital for a CPU "to be fast" in every situation, it's vital for a CPU to be fast with bulk data. If you're working on bits and pieces of information that are hundreds of bytes in length, low cache count is no excuse to be slow.

It's also worth noting that on today SoC's, a lot of data processing is offloaded in different manner. Small cache on a general-purpose CPU that has to do software video decoding has a far larger impact than small cache on an SoC with a dedicated video processor, with its own set of fast-access memory buffers & co..

I'm obviously not trying to imply that a 1 GHz mobile SoC is equivalent in every term of processing power as, say, a 1 GHz network processor or a 1 GHz PowerPC from a Powerbook. But things are actually somewhat better than you paint them to be.

> Many things are already preoptimized on the kernel level, but it doesn't change the fact that even html and javascript parsers, which parse text, will be slower on those devices.

Obviously not. What I am arguing is that having to parse HTML and Javascript in applications that are not web browsers (or which otherwise don't have to browse hypertext because hypertext is essential to their intended function) is superfluous.

Edit:

> Performance will bite you on mobile software.

Performace will bite you on every type of software. It's a mad, possibly rabid dog that hates humans. Some programmers, however, seem very prone to teasing it.

I think the point is more that without a decent cache, the speed of a cpu is greatly throttled to really be the speed of the memory feeding it.

Consider, for much of the task of browsing the web, the largest noticable speed problem is decidedly not the local device, but how long it takes for the data to load.

> Cache memory is not vital for a CPU "to be fast" in every situation, it's vital for a CPU to be fast with bulk data. If you're working on bits and pieces of information that are hundreds of bytes in length, low cache count is no excuse to be slow.

That's why the software and protocol you use on a mobile device should be very much different. To me, desktop and mobile software are way too much similar.

The fact a programmer will fuck up an app boils to the fact twitter will use HTTP, which is text, on top of SSL. This can't be blazing fast for such a low powered device, especially if it's a library API thing you use to make an app on top of it. I think google and the web in general are mostly to blame because they're responsible of spreading text based protocols.

I'm just concerned about mobile software, because the hardware is really really good, but the software had not been adapted for it. We just need protocols and format that are just faster, more compact, and maybe rely on other networking optimizations. bittorrent, for example, is a great example of a reliable binary protocol.

HTTP and HTML were great because they are easy platforms to make something on, but they require more memory because of parsers and more bandwidth because one single web page will often weigh 100ko, and run a javascript engine which is not a simple piece of software.

The hardware has gotten smaller, maybe we also need to make smaller software too ! I agree there are also security concerns about binary protocols, but it's just weird that there are so few open, standardized binary protocols, maybe because developers find working with http being just easier. You can't have it easy all the time.

> The fact a programmer will fuck up an app boils to the fact twitter will use HTTP, which is text, on top of SSL. This can't be blazing fast for such a low powered device, especially if it's a library API thing you use to make an app on top of it. I think google and the web in general are mostly to blame because they're responsible of spreading text based protocols.

I think this paints only part of the truth. About an year ago (I don't know if this still applies today), I grudgingly agreed to see if Phonegap could be of any help to us in a project. The difference in interface alone was noticeable: slider widgets were sloppy and noticeably froze, on a mid-range phone. The same native widget was fine.

Clearly, then, the phone isn't memory- or CPU-starved to the point where it can't paint a slider widget. It logically follows that one implementation of that widget is inefficient (sweet talk for "it's worse than it could be", if not "it's bad").

HTTP over SSL probably does make for slow data transfer on such a device, but it should play little role in a sloppy UI. I've seen fluid, well-built UIs that ran on slower devices, over slower data links (think hundreds of bytes per second or even less). They adequately conveyed the information that the device is waiting for data, or that data is being fed at a slow pace, but they weren't botching.

> If you make an app for a smartphone, you can't really have even one third of the expectations you have on a desktop or laptop computer.

So what you're saying is that in a couple of years mobile phones will be as powerful as today's desktops and laptops?

So any applications you design now that you expect to be relevant in a few years time need to take that into account.

No they won't, until there is a huge breakthrough in battery technology. And please stop talking about "computer power", because most of computer power boils down to how much data per second a CPU can treat, unless you have a really minimal software design. Data per second equates to energy consumption.

Although even today batteries hold quite a lot of power and you can watch it when you break it, lithium battery can be dangerous, so more powerful batteries might not be such a good idea.