Computing in molasses

August 20, 2008

Way back in the 80’s I had a Commodore Amiga 1000 as a home computer. While there was much that was amazing about that machine, it was tedious to write code on — with one 800k byte floppy disk and a multi pass compiler and linker, it took what seemed like ages to edit-compile-run. It was like wading in molasses.

Meanwhile, at work I used DEC microvaxes running Ultrix, and Sun workstations running SunOS, and they were very sprightly. Editing large files with emacs was comfortable, compiling C code was quick, and shell and awk scripts ran fast enough that you didn’t even have to write C unless you had a really big data set to process.

In fact, it was almost more comfortable to dial in to work at 2400 baud and use a terminal session on my microvax than to use the Amiga for developing C code.

This was not the Amiga’s fault. With the limited hardware, it couldn’t be any faster. Add hard disks, more RAM, floating point hardware, and it would have been as responsive as a Sun workstation, but it also would have cost as much.

Things changed around 1990 when I bought a 40 MHz AMD 386 based PC with 120Mbyte hard disk. Initially running Coherent, then Linux, I finally had a home computer that was as comfortable as my work computer. With an add on IIT floating point coprocessor, my 386 system at home was entirely as responsive as the Sparcstation IPC on my desk at work.

And as hardware improved with time, things got even better both at home and at work. With ample computing power, you only got slowed down on serious problems. Most of the time it felt like you were jogging comfortably through the problems, and this happy situation continued until recently.

But now, again, I feel the molasses oozing around my knees, slowing me down and resisting my stride.

How can it be, that with GHz multi-core processors, Gigabytes of RAM, hundreds of Gigabytes of disk, and megabit per second interfaces, the computing experience is anything but instantaneous?

Recently, I have had to make relatively intensive (I mean all day long) use of some software that runs only on Microsoft Windows. This is really unpleasant.

The most unpleasant thing is the poor responsiveness of the system, in particular the irregular time lag between clicking on something and activity occurring. Sometimes things take 1/2 second, sometimes 5 seconds. Sometimes, after a 5 second wait, you think maybe the first click wasn’t seen, so you click again, only to find the first action was actually seen, it’s just that the lag was unusually long, so now you have 2 instances open.

It is not the hardware, or the system configuration. The problem is the completely shoddy software (from operating system up to application), and in particular, the way it is structured.

The problem sets are much larger today than they were 20 years ago, and I know we use interpreted languages with bigger runtimes, and garbage collection, etc, etc. That is not the problem. Modern hardware is more than up to the task. I am still impressed when I run a large program written in python that it runs in a matter of seconds. And then I can rewrite one module in C, wrap it with swig, and get something that runs in milliseconds. This hardware is FAST.

The problem is the software architecture. If you insist on making a GUI application, then you must design the software architecture so that the user interface is responsive, even when something time consuming like network access or serious computation is involved.

If I click on some button to start an action, and a dialog must pop up to ask for some input, then it should pop up quickly every time. I won’t mind if the action sometimes takes 20 seconds or sometimes 25 seconds, but it will break my stride if I have to wait some varying amount of time for the dialog to pop up. This problem is so common on Windows software — sometimes you click the File menu and that takes several seconds to come up.

On microsoft windows, most software is like this. On linux, firefox and open office are like this. I find these programs quite unpleasant to use.

Meanwhile emacs, which people used to deride for bloat — Eight Megs and Constantly Swapping — well, eight megs is basically cache memory now. Sure, emacs has bloated somewhat over time, but it is still a pleasure to use.