4 ms·

It's been said before: old apps on old hardware are a similar speed to today's apps on today's hardware. Often, they're snappier. Faster hardware makes softwar

by 10ren 17y ago

It's been said before: old apps on old hardware are a similar speed to today's apps on today's hardware. Often, they're snappier. Faster hardware makes software slower. Partly it's because they're doing more; partly it's due to inefficiency: Work expands to fill the available time - Parkinson's Law 1. Apps are already fast enough. 2. If we need extra speed to do extra things, we can draw on the reservoir of inefficiencies. Examples: Flash's ActionScript became many times faster in ver 3 (on the order of Javascript to Java). Google improved plain Javascript performance by up to x10 in its Chrome browser. Apple's iPhone is very snappy. 3. We seem to have overshot the need for performance (making it ripe for disruption), and that people value things other than performance, like mobility, size, weight, battery life - as in netbooks and smartphones.

GeneralMaximus 17y ago
Not sure why this comment is getting downvoted. A few years ago, we used to manage just fine with 128Megs of RAM and 500MHz processors. Now, programmer productivity has suddenly taken importance over user experience. As far as desktop apps are concerned, I would prefer a C++ app with a couple of features I need over an extensible, feature-rich app written in Python. WebKit and Gecko have shown us that it is possible to make dynamic languages go faster. Yet, most people start yelling 'premature optimization LOL!!!1!' if you dare to tell them their app is slow.
jurjenh 17y ago
Another thing that (IMO) is a main cause of the slowdown is the sheer scope of possibilities available on general low-cost hardware these days. In earlier times you had to work hard to make your code do all the work in a given space. This meant thinking long and hard about which features to implement, let alone how to implement them efficiently (time + space) - a practice which has disappeared somewhat, mainly because it is relatively cheap and easy to just implement it, then optimise if necessary. Premature optimisation while coding can be a big problem, but this need not mean that optimisation should be left until the end - in fact it is a good idea to optimise the design prior to implementation (that is, at the end of the design process) This means implementation can be done relatively quickly as the key features are already decided.
fauigerzigerk 17y ago
old apps on old hardware are a similar speed to today's apps on today's hardware. Maybe, but very often they don't do the same thing, which makes the comparison useless. I don't remember being able to search and rank billions of documents in sub second time back in the 90s or mine terrabytes of data to find cures for cancer. We now do predictive analytics where we did quarterly reporting in the 80s and 90s. Let's not view computing primarily as word processing with 500MB of bloat added in each new version :-)

by 10ren 17y ago

GeneralMaximus 17y ago

Not sure why this comment is getting downvoted. A few years ago, we used to manage just fine with 128Megs of RAM and 500MHz processors. Now, programmer productivity has suddenly taken importance over user experience. As far as desktop apps are concerned, I would prefer a C++ app with a couple of features I need over an extensible, feature-rich app written in Python. WebKit and Gecko have shown us that it is possible to make dynamic languages go faster. Yet, most people start yelling 'premature optimization LOL!!!1!' if you dare to tell them their app is slow.

jurjenh 17y ago

Another thing that (IMO) is a main cause of the slowdown is the sheer scope of possibilities available on general low-cost hardware these days. In earlier times you had to work hard to make your code do all the work in a given space. This meant thinking long and hard about which features to implement, let alone how to implement them efficiently (time + space) - a practice which has disappeared somewhat, mainly because it is relatively cheap and easy to just implement it, then optimise if necessary. Premature optimisation while coding can be a big problem, but this need not mean that optimisation should be left until the end - in fact it is a good idea to optimise the design prior to implementation (that is, at the end of the design process) This means implementation can be done relatively quickly as the key features are already decided.

fauigerzigerk 17y ago

old apps on old hardware are a similar speed to today's apps on today's hardware. Maybe, but very often they don't do the same thing, which makes the comparison useless. I don't remember being able to search and rank billions of documents in sub second time back in the 90s or mine terrabytes of data to find cures for cancer. We now do predictive analytics where we did quarterly reporting in the 80s and 90s. Let's not view computing primarily as word processing with 500MB of bloat added in each new version :-)