Windows 7 offers the possibility for a process to set its IO priority to "background". This is something the bitcoin client would certainly profit from, as it tends to read/write lots of data at times and while it does, it shouldn't interfere with other (more important) processes, like media players etc.
See: http://superuser.com/questions/136021/how-to-change-i-o-priority-of-a-process-or-thread-in-win7
I tried this (launched the whole program at low IO priority), yes it works quite well in making not interfere with other programs. It also made the whole (Bitcoin) program very slow at times of high resource contention. (although that might be better if only one thread was running at low IO priority). I don't think this feature was designed with programs with constant IO in mind, it turns off read ahead (and does various other things) so it can stop HD reading at a moment's notice and not impact other programs. I witnessed significant blocking (in the programming sense) when syncing the block chain, the TCP window was almost always full while downloading slowly. Back to normal IO (relaunch) -- 50x faster.
But for a high IO program like Bitcoin low IO priority makes the HD thrash like crazy. It didn't make the computer slower than bitcoin with normal IO even with all that thrashing (IO priority works great. [Thanks Win7!]). I don't think this is a good idea to use for bitcoin.
Some people may prefer to have bitcoin sync as fast as possible given your computer. Others don't care about sync speed and rather have it slow in the background.
We have been avoiding those kind of automatic settings on other platforms like Mac (app nap). In which case people complain about it slowing down bitcoin sync.
There is already a setting to make bitcoin use fewer cores: -par=, or in the 0.9 GUI "Number of script validation threads". If you set that to 1, for example, it will only use one thread instead of the default, one per core.
Sure there may be reasons to change the IO priority instead, but I also don't think this should happen automatically.
I remember we once had set different priorities for our threads, which was removed by some thread rework pull. Well this issue talks about the whole bitcoin process, but I'm unsure we should add this. Not just for Windows IMHO... you can also set the priority via the Windows Task Manager already.
We are talking about IO priority, not CPU priority. It (like CPU priority) can be changed dynamically, but there are few if any tools that can do it.
Sorry I misread your issue then.
Still, reducing the number of threads with par= is the primary way to reduce load on your system. You can play with CPU and I/O priority but that does get into micro-management.
"[...] there are few if any tools that can do it."
You might want to have a look at this: http://sourceforge.net/projects/iopriority/
I used it for testing. That is how I found out what was making my video playback on VLC lag (Bitcoin syncing).
It is understandable though that having Bitcoin run at low IO priority might not be the best solution for everyone, however at the same time I can imagine that having Bitcoin interfere with ordinary video playback on your PC could be the kind of bad experience that might make people look for a different client or leave Bitcoin altogether. Therefore there should at least be an option within the settings to run Bitcoin Qt with low IO priority by default.
In my opinion limiting your connections is also a good way to throttle I/O. Capping the disk is not going to do what you want very well. setting -maxconnections=5 or 10 (default: 125) would be the best way to slow down the client in a more meaningful way. There are also guides that saying running it with "nice" on *NIX also helps. There are similar tools for windows. http://stackoverflow.com/questions/4208/windows-equivalent-of-nice
@OldDeath so have you actually tried scaling down with -par=1 first? I'm still unconvinced that changing IO priority is needed to make bitcoin a good citizen. But by default it creates a thread for every core, which during initial sync will have a high load (if you have a fast sync node / bootstrap) so understandably can hold up other processes. Scaling down the number of threads is the most straightforward way to avoid this.
The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.
Closing due to lack of interest. Pull requests with improvements are always welcome.