Solomon once said not to pine for the good ol’ days, and that’s sage advice, but I’m sure he didn’t intend it to apply to software bloat.
I’m not just talking about memory and megahertz bloat — we’ve also got performance unbloat. And it almost seems like the two go hand-in-hand. The more memory something hogs, the slower it’ll run.
- Foxit is a 2.5 MB download, Adobe is a 25 MB one.
- Foxit uses 8 MB of memory for a 700 KB PDF, Adobe uses 56 MB.
- Foxit loads in about 1 second, Adobe in 4 seconds.
- Foxit is as fast or faster to use.
Maybe it helps (or hinders) to be an embedded programmer, and know how much you can do with 32 KB of code, 2 KB of RAM, and an 8 MHz, 8-bit processor. Sometimes I wish developers had to write code on ancient 66 MHz 486s. Constraints are the mother of optimization, and programmers will usually forget about optimization after it runs “fast enough” on their 42-core Pentium IX, 10 TB RAM development machine.
Sure, I grant that RAM and clock cycles are cheap these days, and we might as well use ’em. But surely there’s a limit to all this. When my (plain text!) editor runs slow enough so I can see the screen updating, there’s something wrong.
When Visual Studio takes 2 entire seconds to pop up a simple properties window the first time, there’s something wrong.
Back in the days when programmers cared about how many characters they could write to video memory during the CGA horizontal retrace time without it producing snow — back in those days, and running on a 286, I couldn’t see my screen updating.
We now have 1000’s of times the computing power, and as far as user experience is concerned, stuff runs slower than it used it. And we put up with it, because they’ve added one or two features we like, and it’s “good enough”. But it just ain’t right.
And it’s not just the my text editor and Visual Studio. When Thunderbird first came out, it was so slow on my fairly average hardware that I simply couldn’t use it. And now on my 2 GHz dual-core whatever-it-is, it’s still slow. I click on Inbox the first time, and it takes a second and a half for the message to pop up. Come on, people — you could load a usenet thread off a floppy drive in that time!
Somehow we’ve convinced ourselves that Gmail’s conversation view and anti-spam features make it worth putting up with 750 millisecond Ajax delays all the time. Nope, it just ain’t right.
Recently I was reading from Michael Abrash’s Graphics Programming Black Book, and he has something telling (albeit provocative) to say about all this in chapter 2:
You will notice that my short list of objectives for high-performance assembly programming does not include traditional objectives such as easy maintenance and speed of development. Those are indeed important considerations— to persons and companies that develop and distribute software. People who actually buy software, on the other hand, care only about how well that software performs, not how it was developed nor how it is maintained. These days, developers spend so much time focusing on such admittedly important issues as code maintainability and reusability, source code control, choice of development environment, and the like that they often forget rule #1: From the user’s perspective, performance is fundamental.
My theory is that it’s gonna take an RMS-style prophet to come along, take a few pages out of Abrash’s book, write his own instant-GUI operating system, wake up the masses to the joy of responsive computing, and watch the bloat industry crumble.
It’ll be a world where you can turn on your computer and use it immediately. A world where you wait at most half a second for big programs to load. A world where your screen will update even before the keyup event is sent. It won’t be utopia, but I’m still looking forward to it.
We’re taking submissions for this kind of prophet. Drop your résumé or CV in the comments below. :-)
27 June 2008 by Ben 27 comments