Raymond writes an interesting post about how some programs run faster if you hold down the mouse.

This is a classic situation to get yourself into – I’ve probably seen it 5 times, and hit it again recently.

When we’re burning a DVD, the burn engine calls back into the UI layer so that we can update the progress bar. To give the user a single monotonically-increasing progress bar, we (well, Dean, actually) have to play some games with our progress tracking, which means that sometimes we get progress callbacks once a second, and sometimes we get them 100 times a second.

The progress dialog looks fine, but if you look a profile of the burn, you’ll find that a fair amount of time is being spent in the UI code updating. In this case, it’s not a big deal, but I’ve seen cases where programs are spending 90% of their time updating the UI. That takes a 10 second operation and makes it take 100 seconds, which is pretty bad.

The fix? Well, there are two good ones.

The simplest one is to simply update every <N> calls. I traditionally start with N=10, which is guaranteed to same 90% of the overhead, and usually works fine.

If your callbacks are sporadic – as they are in the DVD Maker case – it works better to timebox the updates. Whenever you update the UI, record the time, and then don’t update it again until a specific time has gone by. I usually find 1/4 second to work well.

Paul wrote an informative response to my post on collaboration.

I’ve just been writing some stuff about where I think our group should go in the future, and I’ve decided to downplay pair programming. Not because I think it’s a bad idea, but more because I think that opinions around it tend to be a bit religious.

Instead, I’ve decided to advocate an open environment where pairing can happen in a natural way