ArticlesMy recent entry condemning unresponsive applications took me a long time to write. I knew I was frustrated with unexpected software slowness, but I couldn’t put my finger on why.
I realise now that I was confounding three separate problems.
Unresponsiveness
An application is unresponsive if, while working on a task, it fails to respond to background user or operating system requests. The two canonical examples are failing to repaint the screen or failing to abort upon request.
I realised a couple of days ago this was the pet peeve that was causing most of my frustration.
- Don’t start long operations in the UI thread; push them off into a different thread. Developers should consider their priorities of fast-to-develop versus fast-to-respond, and remember that I am lobbying to generally raise the fast-to-respond priority.
- When you block a thread listening for an event, you should also be listening for an abort signal.
- If you are doing highly CPU-intensive work, ensure that the OS can abort the thread easily you, or you need to sprinkle in some tests for an abort signal inside the big loops. Yes, this might have some performance impact. The developers should carefully consider their priorities of fast-to-finish versus fast-to-respond. Again, I am lobbying to raise the priority of fast-to-respond.
Unexpected CPU Hogs
Another frustration that I was confounding was software which unexpectedly consumes a lot of CPU – the applications you stare at while scratching our head and wondering what they could possibly be doing that needs all that much CPU.
Applications that do busy waits should be punished punitively, while buggy applications that get into an infinite loop deserve more of our compassion and help at rehabilitating.
Outstaying their Welcome
My bus is leaving. The meeting is starting. There’s a fire alarm. I am off to get a drink while my machine restarts. Whatever my reasons for shutting down, I expect that my applications shut down quickly and without protest. Don’t make me reach for that power button!
The number three frustration is applications that come up with lousy excuses for not quitting when they are told.
Perhaps there needs to be some OS support in this area, so programs can save their intermediate data into a known temporary store so they don’t need to ask me “Do you want to save?” Just re-open the half-finished documents on reboot and let’s get on with it.
Summary
So there are at least three different frustrating issues that mean that my super-fast machines don’t act super-fast. Developers need to start thinking more about the impact these issues have on their users before the revolution comes.
Comment by Richard on June 12, 2006
I think MS Office has really outdone itself when it comes to bad shutdown behaviour: when you happen to use the Start > Turn Off Computer > Shutdown, even when there are no documents to save, Office has the temerity to pop a dialog saying “you can’t quit me like that. You’ll have to tell me directly instead,” or words to that effect. This is especially annoying as it aborts the shutdown!
BTW as Casey would probably go on about, indexing the files on your hard drive (as Google’s tools do) is likely to be CPU rather than IO bound: it has all sorts of shenanigans to do with the text before it writes to the index files. All of this so you can search for phrases, rather than just single words and have the results quickly. But it could also just be a memory issue… The app could be loading the whole index db into memory and then trying to grow it dynamically as it reads more text (causing the GC to thrash), but that would be poor design, rather than inherent to the problem.
Comment by Julian on June 12, 2006
Richard,
I keep going backwards and forwards on the topic of Google Desktop Search.
On my work machine, it is the greatest thing since sliced bread – in fact, since before then. If you asked me which would I rather give up – eating pre-sliced bread and using Google Desktop Search, I would give up sliced bread.
On my home machine, it always seems to be consuming CPU – GoogleDesktopCrawl.exe often sits at just below 50% mark, probably only stopping there because it can’t work out how to use the second (hyperthreaded) processor. Right now, it is at 49% and has consumed over 19 hours CPU time since my last reboot, which was 6 days ago.
Sometimes I think “Hey, it is processing my indices, it is a low-priority task (or at least, I hope it is) on an underutilised CPU so it isn’t impacting me. Who cares?”
Sometimes, I think “I must have some spyware, storing my credit card information onto my hard-disk at a rapid rate, and Google DeskTop Search is carefully caching that!”
Sometimes I think “Wow, 19 hours of CPU in 6 days? I should turn it off and see if I can tell the difference on my quarterly power bill!”
Comment by Aristotle Pagaltzis on June 12, 2006
You are deranged. Thoroughly deranged. :)
Comment by Sunny Kalsi on June 12, 2006
Google Desktop using 50% CPU certainly is odd. I use beagle, which is sort of a linux equivalent. It only indexes your home directory and anything else you choose. It’s pretty smart about the amount of CPU it uses, and I’ve never noticed it impact my activities, save for bugs. One of the things I can think of with Google Desktop is that it’s re-indexing files that are continuously changing, which can happen with some software applications. If your work does not use 50% CPU then that might be the case.
Comment by Julian on June 13, 2006
Aristotle,
Is your comment related to the original article or my calculations? Please elaborate…
By the way, I forgot to mention, all calculations in Australian dollars.
Sunny,
Yeah – it probably is a bug or some adverse interaction with some other software I am running. I have reinstalled and I have searched for solutions, but no sign yet.
Comment by Cassie on June 13, 2006
Julian, Aristotle’s comment has to be about your sliced bread comment. Sliced bread is highly overrated. Unsliced is where it’s at. None of this eating a slice the thickness determined by the bakery. No way. You’d have to be deranged to do that. Plus, leaving the bread unsliced protects it from becoming stale too quickly.
BTW I’d shower for shorter periods. I’d even consider giving up unsliced bread for shorter periods. I’d consider anything for shorter periods. Bring on shorter periods! Or at least less painful ones. Sorry guys.
Comment by Aristotle Pagaltzis on June 14, 2006
You are all deranged. Thoroughly deranged. :)