- The first is that programmers worry unnecessarily about the things that a computer does extremely quickly. (It so happens that it was just such a concern "incrementing a value 300 times per secondincrementing a value 300 times per second" that led me here in the first place.)
- The second is that they sometimes fail to show due concern when things do take a very long time (on the computing timescale). So:
- if they ignore the effects of latency when communicating over a network or with a storage device;
- if they ignore the impact of a thread blocked and waiting for another thread;
- if they forget that because computers work so quickly it is very capable of repeating a task far more often than it should, without the developer being aware of a problem
- ... if any combination of such oversights occur, a routine will unexpectedly run very slowly (on the computing timescale). A few repeats and it will even be noticeable by humans - but may be tricky to pin down because hundreds of interconnected things are all running quickly by themselves.
|2||replaced http://stackoverflow.com/ with https://stackoverflow.com/|
Is it because these were all written in managed, garbage-collected languages rather than native code?
No. Slow code will perform poorly regardless. Sure, a particular language may introduce certain classes of problems while solving others. But good programmers are quite capable of finding workarounds given enough time.
Is it the individual programmers who wrote the software for these devices?
Partly. In many cases it is quite likely at least a contributing factor. This is an unfortunate side-effect of an industry where good programmers are in high demand and short supply. Also the gulfs between various levels of technical ability can be quite large. So it stands to reason that sometimes the programmers tasked to implement certain software could be congratulated just for getting it to work (sort of).
In all of these cases the app developers knew exactly what hardware platform they were targeting and what its capabilities were; did they not take it into account?
Partly. For a start, the exact hardware platform is probably not known, as that is often negotiated with various manufacturers in parallel during software development. In fact, there can even be small (but not necessarily insignificant) changes to underlying hardware after initial release. However, I would agree that the general capabilities will be known.
Part of the problem is that software probably isn't developed on the hardware, it's done in emulators. This makes it difficult to account for true device performance even if the emulators are 100% accurate - which they aren't.
Of course this doesn't really justify insufficient testing on the appropriate prototype hardware before release. That blame probably lies outside of dev/qa control.
Is it the guy who goes around repeating "optimization is the root of all evil," did he lead them astray?
No. I'm pretty certain they don't listen to him anyway; otherwise he wouldn't be misquoted so often (that's supposed to be "premature optimisation ..."). :-D
It's more likely that too many programmers take one of 2 extremes with regards optimisation.
Was it a mentality of "oh it's just an additional 100ms" each time until all those milliseconds add up to minutes?
Possibly. Obviously if
The thing is modern computing hardware (including embedded devices) is much faster than people give them credit for. Most people, even "experienced" programmers fail to appreciate just how fast computers are. 100ms is a long time - a very long time. And as it so happens, this "very long time" cuts 2 ways:
Is it my fault, for having bought these products in the first place?
Yes definitely. Well, not you personally but consumers in general. Products are sold (and bought) by feature checklists. Too few consumers are demanding better performance.
To illustrate my point: The last time I wanted to buy a cell-phone, the store couldn't even offer a demo model to play with in-store. All they had were plastic shells with stickers to show what the screen would look like. You can't even get a feel for the weight like that - let alone performance or usability. My point is that if enough people objected to that business model, and voted with their wallets to voice their objection, we would be one small step in the right direction.
But they don't, so we aren't; and every year new cell-phones run slower on faster hardware.
(The questions not asked.)
Basically, I believe there are many contributing factors. So, unfortunately there's no silver bullet to fix it. But that doesn't mean it's doom and gloom. There are ways to contribute to improving things.
So, at what point did things go wrong for these products?
IMHO we can't really identify any single point. There are many contributing factors that evolved over time.
What can we as programmers do to avoid inflicting this pain on our own customers?
I have a few suggestions (both technical and non-technical) which may help: