The Slowening of Faster Devices

Cueing Up An Ad

Come here and see this cool PBSpromo that was just on!” I call to my wife,tapping pause on the PVR’s remote. Given my history of calling herin for replays that weren’t as hilarious or amazing as I originallyimagined them to be, I knew this had to be a slick presentation ifI wanted to impress with my PVR-fu.

As she enters the room the PVR finally reacts to my command,pausing, but then immediately playing again: Once again I’ve beencaught out hitting the button twice, assuming that the firstrequest got lost in the ether — as often happens — when it didn’tseem to respond in a timely manner.

I hit pause again and this time it immediately reacts, coming toa halt.

I just have to cue it up,” I say, buying sometime.

I tap rewind. Nothing happens. Come on, I think, I’ve got animpatient audience here! I tap it again, and the box launches intodouble speed rewind as I race for the play button. It plays ondemand, but now it’s several minutes before the desired startpoint.


Unpredictably high user interface latency strikes again. Whilethis Motorola PVR is an exceptionally bad culprit for randomnon-responsiveness, it’s hardly the only example of this seeminglygrowing trend.

User Interface Lag

My Moto Qsmart phone is a great little device that I really enjoy, but theuser interface responsiveness is enormously uneven,frequently lagging several seconds behind commands. Whether waitingfor it to complete an application switch, or even during basicinteractions such as entering a URL in the address bar of PocketInternet Explorer, it’s often out to lunch.

Presumably the questionable multitasking of Windows Mobilecompletely blocks the user-interface thread when it decides tochatter with a cell tower. Nothing else can explain itsbehaviour.

On startup my DVD player apparently needs to initialize its ownlittle operating system, and if there’s a disc in the drive itautomatically demands that it determine the contents before it willeject. It insists that it be able to put “DVD” on the front-panelbefore any other activity occurs, achieving siliconself-satisfaction that it accurately determined the media type.

A common scenario has us getting ready to leave the house,preschool children bubbling with energy, when we realize that wehave a disc that we should return to the movie store.

Turn on the entertainment unit. Wait for DVD to pre-powerinitialize. Hit eject on the front panel (which automatically turnsthe unit on). Wait as DVD player initializes and then unnecessarilyspins up the disc in the drive to read the disc type and rootmenu.

Finally it ejects.

It isn’t just household devices that show this worrisome trend.The bank recently “upgraded” their ATM machines, bringing acolourful, graphical façade to what was once a glowing-green,ASCII, very serious interface. What once was a quicknavigation through the menus now sees the painful redrawing ofscreens and laggardly keystroke responses.

Seconds Add Up To Minutes Add Up To Hours Add Up To…

It might only be 10 seconds or so from beginning of DVD ejectprocedure to the actual ejecting of said optical disc, but that’sapproximately 9.75 seconds more than it needs to be.

When time is short, even small delays like this can beincredibly irritating.

Despite the increasing computational capacity of our devices,the problem seems to be getting worse. User interfaceresponsiveness seems to lie low on the list of priorities in manycontemporary electronic devices.

These devices seem to be growing slower and slower, yet theprocessors that power them are getting dramatically morepowerful.

A Supercomputer in Your Hands

Slashdot recently had a story linking to some reviews of a new Windows Mobile 6 smartphone. Several of the comments providedvariations of the argument that the primary weakness noted in thereview — poor performance — was the result of “underpowered”hardware.

Throw some more hardware at it and everything would be okay, theargument goes.

Consider that for a moment: is hardware really the problem? MyMoto Q — a device that often demonstrates terrible responsiveness(I’m not trying to pick on Motorola — I’ve noticed the samebehaviour with Nokia and Audiovox phones) — is powered by an IntelXScale PXA272 processor running at 312Mhz. It comes with 64MB ofRAM, 128MB of flash memory, and I’ve supplemented it with 1GB ofminiSD flash storage.

Is that an insufficient bit of hardware to manage the awesometasks of a smartphone with a 320×240 screen?

As a point of historic comparison, in the late 80s I was a proudowner of an Atari520ST. It was a multimedia powerhouse powered by an 8MhzMotorola 68000.

Despite featuring a laughably anemic CPU, by today’s standards,it seemed infinitely capable at the time: I used it to createcomplex reports for high school in a full featured desktoppublishing app. I did hobbyist software development in a rich IDEon it. I wasted away countless hours trolling local BBS’. It evenwas a wonderful game platform, running richly challenging gameswith gusto (games far more advanced than what you often findrunning in J2ME on your cell phone).

Later I upgraded to the Atari 1040STE, still with the same 8Mhz68000, but offering expansion capacity to bring it up to a colossal4MB of memory. This was so much memory that I usually created amemory “disk” out of 3MB of it, and still never felt limited in the1MB.

Seldom did my ST ever feel laggy or non-responsive — it bootedclose to instantly from ROMs, and the simple UI was alwaysextremely responsive. Demo programmers had it doing tricksthat still impress me to this day. Later a UNIX-style OS was ported toit, including full pre-emptive multitasking.

So how does that relic of the past compare with something likethe Moto Q? Comparing straight Mhz isn’t a valid comparison (forinstance the ST is a CISC processor, versus the RISC XScale), so Iwent searching and found some Dhrystone 1.1 benchmark numbers forboth the XScale at 312Mhz and the 8Mhz 68000.

8Mhz 68000 (Atari ST) – ~1,603 Dhrystones / second

312Mhz XScale PXA272 – ~731,512 Dhrystones / second

On this benchmark the PXA272 in the tiny little smartphone on mybelt (yeah, I’m a nerd) is equal to 456 Atari STs. Let’s look atthat in a bar graph in case it isn’t clear enough.

8Mhz 68000 1,603 Dhrystones / second
312Mhz XScale PXA272 731,512 Dhrystones / second


Memory wise the Moto Q has a virtually infinite amount of memorycompared to my old Atari ST.

I’m not trying to pretend that the ST of old did what a PDA oftoday is doing: I remember first getting access to low resolutionJPEGs on a local BBS (I was a teenager and they were swimsuitphotos…pretty risqué at the time. This stuff was much tamer thanan issue of Maxim magazine or an “Umbrella” video), having to gothrough the tedious process of first “decompressing” them to a TGA,waiting as the decompression processed for sometimes minutes, andthen viewing the uncompressed image. There was no way it couldrealtime do something as complex as rendering a JPEG.

Yet considering this enormous increase in computational power,it does seem evident that many device developers aren’t respectingthe time of their users, and few users are calling out terribleinterfaces for being unresponsive and disrespectful. Reviewers, inparticular, seem blind to responsiveness when rating devices,presumably because the artificial environment of a review can’t becompared to quickly trying to respond to an email while standing inan airport terminal just as the last boarding call is made.

The Basics of a User Interface

A user interface should be predictable and consistent — itshould always respond in a short, consistent amount oftime (I would honestly feel that the PVR would be better if italways took 3 seconds to react to a command, versus now when it’sanywhere between 0 and 5 seconds), always allowing the user tocancel operations that they’re no longer interested in.

Responding to the user’s input should always be job #1.