Recently in Performance Category

I recently noted that Vista has some interesting new behaviors regarding applications that are launched from the Startup folder.  By default, their I/O priorities are throttled back for a total of one minute from launch.  This is a good idea to keep lots of smaller or background-use applications from all starting up at once, but it doesn't seem to be such a good idea if you try to boot an application like Outlook, which is by nature I/O intensive, by putting it in the Startup folder.

To that end, I tried a few experiments.  I wrote a batch file to start up several major applications -- Outlook, Word, Windows Live Writer, AIM and at least one or two other things -- and put it into the Startup group.  Between each program launch, I instigated a forced seven-second delay by using the CHOICE command (a sneaky trick I picked up from somewhere).  I wanted to see if this would cause any difference in the amount of utilization or responsiveness.

When I used this to launch the programs in question, all of them were launched at the Very Low I/O priority -- and the end result was that they were all fairly difficult to work with during that low I/O period.

I then took the same batch file out of the Startup group and ran it from the desktop after a cold boot.  The programs in question all started up quite snappily and I could choose between any of them without difficulty -- and they were all running at Normal I/O priority, too.

So here's my tentative recommendations for what to put in the Startup group.  Much of this advice may be redundant but I'll elaborate where needed.

1. Include programs that run by default in the background and are not things you typically work with directly after logging in.  AIM, for instance, is a good candidate for this sort of thing.
2. Don't include major applications like Word or Outlook.  Launch those manually so you can benefit from those getting the maximum I/O priority.  (My above script seems to work nicely for group launching, although I had some minor window-focus issues that I think I can solve relatively easily.)
3. Don't include applications that will block other things until they complete heavy I/O operations.  Since they launch with very low I/O priority, they'll essentially be stuck until that bar lifts.

[Note: An earlier version of this tip had some inaccuracies which were brought to my attention.  Thanks to Ed Bott for his keen eye!]

[Note #2: Ed's published a blog entry about this issue, and some additional notes that are well worth reading -- including a super-useful link to a tip on how to customize the way the Disk Cleanup tool runs.]

This is actually not an indictment of Vista alone, but something I've seen in Windows for quite some time now: the user profile \TEMP directory.  It fills up with the most amazing amount of trash imaginable, and over time it can cause programs to malfunction left and right in ways that defy analysis.

Vista does have a way to deal with it: the Disk Cleanup tool. which purges the \TEMP directory on demand.  However, as a safety measure, it doesn't delete anything newer than one week -- for instance, temporary files created as part of a program's installation process.

If you want to manually purge the \TEMP directory without the date cutoff restriction -- just blast everything in there -- here's one way to do it.  Copy the following into a text file with a .BAT extension:

rd /s /q "%localappdata%\temp" && md "%localappdata%\temp"

(That's all one line, by the way.)

When run, it'll erase the entire contents of the TEMP directory and then recreate it anew.

Two caveats:

1. If there are any files that are in use in the directory, they will not be deleted.
2. As hinted above, do not run this command when you're in the process of installing software, such as before a reboot to finalize a program installation.  It may delete components of the installer that are needed after the reboot.  (Note that if you attempted to install a program and the installer failed and left garbage in the \TEMP directory, it might not be a bad idea to purge all of that before attempting to re-run the installation.  Just make sure the installer is not actually running before attempting this!)

Not long ago I posted about using the Reliability and Performance Monitor tool to figure out where all that disk-bashing was coming from in Vista.  After some feedback from people "in the wild" and some work on my own, I've found the two biggest sources of unexpected disk activity are:

1. The defrag application running in the background, and
2. Volume Shadow Services.

The latter is the one most people are not immediately aware of.  I've noticed that VSS kicks in on a notebook when you bring it up out of hibernation or sleep mode, and it's been off for a long enough period of time that a new shadow copy repository is about due to be created.  When this happens, you see a lot of disk activity that doesn't seem to be related to anything -- and, as I've found, if you start doing regular work with the computer, it doesn't seem to affect performance very much, since VSS runs at a lower I/O priority than most other things.  (The same goes for defrag.)

Here's how I figured it out: the next time I fired up my notebook and saw the disk bashing, I used the R&PM to single out disk activity and sort it by writes, and looked at the File column.  Sure enough, the file in question was one of the shadow-copy repositories (found in the hidden C:\System Volume Information directory).  You could turn off System Restore to prevent this behavior, but to me, that's kind of self-defeating -- especially since System Restore and shadow copies have saved my bacon more than a few times.

As it turns out, the scheduling for how System Restore runs is now controlled in Vista by -- you guessed it -- the Task Scheduler.  A default task is created for creating System Restore points, and I'm going to look into seeing if there's some way to tweak how it's triggered so that it works better with my particular habits.

One relatively undiscussed feature of Vista, which I've touched on here in the past, is the Reliability and Performance Monitor, a quick-and-dirty way to find out exactly what's using what resources in your machine.  A common complaint about Vista is that the hard drives are always churning, which is in turn often attributed to the indexing service.  Sometimes that is indeed the case, but what if it's some other piece of software, and you want to find out whether or not the indexer is really the culprit?

To launch the R&PM, just hit Start and type perf in the Search box; it should be one of the first things that comes up.  You'll need to say yes to a UAC prompt, and then you'll be presented with the R&PM main interface.  Click Disk to expand the disk-access panel, and look for SearchIndexer in that list (you can click on the "Image" column to sort by process name to speed things up).

In this particular example, I've sorted by the "Write" column (which is expressed in bytes per minute).  The SearchIndexer.exe process is indeed at the top of that list, but it's only written 500K or so in the past minute of time (which is a miniscule amount of disk activity).  The "Response Time" column is also a strong clue as to how much of a hog that particular process is: 10 milliseconds is relatively small.  So any disk-bashing that might be taking place wouldn't be the fault of the indexing service.

My way to determine what's bashing the disk is to sort by both Read and Write columns (and Response Time), and see what comes to the top of the list after a minute or so.  If the results are an application, then you can look into any possible problems with that app.

A small follow-up on my previous note about the Outlook patch.  One of the problems I did have consistently with Outlook 2007 before applying it was that sometimes mail queued to go out would stall interminably in the outbox before it would finally send.  After the update, this has not happened.