So, there is no getting around the fact that Windows Vista is, well, a rather large Operating System and has a bit of a perception problem regarding performance. The real problem is not that Vista is, at heart, terribly bloated, it’s that the system’s default configuration makes assumptions about the awesomeness of your computer that are, in many cases, perhaps a little over optimistic. This is especially true with lower-end mobile computers and compact sub-notebooks.
Specifically, Vista, out of the box, is tuned for a system with a fairly fast disk subsystem and lots of physical memory. This is especially important to note because the disk subsystem actually has more of an impact on the total perceived performance of Vista than potentially any other system component, based on my own informal testing (please note, that none of these statements are official cannon from, or sanctioned by, Microsoft and are based on my own testing and assertions).
SuperFetch
The first major contributor to potential performance issues, on low-end systems is SuperFetch. SuperFetch is a very neat technology that essentially implements a page-prefetching scheme. Put simply, SuperFetch maintains a system-wide profile of the most commonly used groups of pages (memory mapped files such as DLL’s and application files, etc.) and then speculatively loads said pages into the systems standby page list, more commonly called the System Cache (technically, in Windows 6 there are 8 standby lists, structured by priority). This prefetching is ongoing, so as pages of non-allocated (totally unused) memory become available, SuperFetch loads these pages with code/data and places them on the standby list. When those pages are actually needed by a process, such as loading a commonly used data file, or launching an often used application, the pages are already in memory and are simply moved from the standby list to the applications working set, thus negating the need for disk IO. Furthermore, if you leave applications running, the memory manager may move pages from a processes working set to the standby list to increase the pool of “available” memory. When you launch a new application, those pages will be dropped from the standby list in order to satisfy the new applications need for process working set allocation. However, upon exit of the memory hungry application, SuperFetch will begin repopulating the standby list with those commonly used pages so as to improve responsiveness as soon as you switch back to using that commonly used application.
On systems with large amounts of memory (2GB or more) and fast, low-latency disk systems (5.0 or better disk score), SuperFetch is a real boon to those who often leave large numbers of applications running concurrently and it really does radically improve general system responsiveness for commonly used applications, OS components and access to data files. I can’t stress this enough, if you are running Vista with 2GB or more of memory (especially 4GB or larger 64bit configurations) with a fast disk subsystem (16MB of buffer/cache, 7200RPM, etc.) turning off SuperFetch is actually a bad idea and will lower system responsiveness.
However, if the system in question is a low-memory configuration (1GB or less) and, most importantly, has a slow disk, SuperFetch can have a very negative impact on performance because it does increase background disk IO activity substantially, most notably during startup and especially on computers where the system is under memory pressure, causing pages to be evicted from the standby list but then in short order potentially reloaded, from disk, to the standby list. Vista goes to great lengths to minimize this situation by implementing a set of page priorities, but this solution becomes less effective as the system becomes more constrained from a physical memory standpoint.
Additionally, machines with relatively slow spindle rotation speeds, low areal density and small disk buffer/cache will be impacted by the IO overhead of SuperFetch far more than a systems with a fast disk. Essentially, below a 4.9 rated disk on a system with 1GB of memory, SuperFetch’s benefits are (in my testing) usually outweighed by its overhead. Even on systems with 2GB of memory, but a very slow primary disk (4.7 or lower Primary Disk WinSat score), SuperFetch’s IO may negatively impact performance, rather than improve it. Conversely, a 1GB configuration on a system with a fast primary disk may still perform better with SuperFetch enabled. My general rule of thumb though is that if the system has 1GB or less, or if the system has a disk score below 4.8, I disable SuperFetch.
Search Indexer, NTFS Disk Defragmenter
Vista implements some impressive new low-level features aimed at making disk IO less impactful with the most important core feature being prioritized IO (you can read more about how IO priority is implemented here: http://technet.microsoft.com/en-us/magazine/cc162494.aspx). With the advent of prioritized IO, Windows now attempts to run a number of background tasks using IO priority below that of standard interactive processes. This is probably one of the most important changes in the Windows 6 codebase and has some really impressive performance benefits.
When Vista runs a NTFS Disk Defrag job, performs indexing for the Windows Search service or runs a Defender scan (or any Vista optimized AV product), the IO for those tasks is done with Background IO priority. This essentially eliminates the foreground impact of low-cpu, but high IO utilizing applications. There is, however, one caveat, and that is if your system has a relatively small disk buffer/cache (8MB or less), this background IO will increase, noticeably, IO latency for foreground processes by overrunning the disk subsystems hardware cache/buffer. The more cache present, less of an impact background IO will have.
The most significant case where this becomes a problem is when background IO tasks (such as Indexing or Defrag) occur in tandem with SuperFetch IO. This, on a slow system leads to pretty significant issues. As stated above, the first recommendation is to turn off SuperFetch on slower, low memory machines. However, if performance during background IO tasks, such as defrag or indexing, is still very poor, then modify the systems advanced power settings to balanced, which will set the indexer to be less aggressive, or disable Windows Search altogether. Also set the scheduled disk defrag job to only run manually and modify other background applications (such as Defender, AV, etc.) to run on a less aggressive schedule. Note, however, that in general, only the SLOWEST systems (or Virtual Machines) should require this step. I highly recommend turning off SuperFetch as the first step and avoid modifying defrag and Windows Search indexer changes, if at all possible, as the loss of functionality and potential long-term performance impact is far greater than the benefit in all but the most extreme cases.
ReadyBoost
ReadyBoost is one of the most poorly understood Windows Vista features. Unfortunately, due to poor initial messaging around what ReadyBoost is and does, it is often misunderstood as a way to increase the available memory on a system. ReadyBoost is, quite simply, a write-through, page-file cache used for random 4k in-page operations by the memory manager.
When you insert a flash device that meets ReadyBoost specifications, you have the option of using the device to cache a portion of the system pagefile. The advantage of doing this is that for scattered IO operations against the pagefile, such as pulling in a random page of memory, a flash device has nearly 0 latency compared to a conventional, spindle-based, hard disk drive. This means that a page can be read back into memory much faster, thus improving system responsiveness, versus getting that page from the primary disk. However, for large sequential (contiguous or large page) operations, a traditional hard drive offers far greater sustained throughput versus a flash device, so those operations will occur against the primary page file. In addition to speeding up random in-page operations, there is a small degree of concurrency that occurs for paging operations (wherein both devices can be servicing IO’s in tandem), which also can positively impact performance.
ReadyBoost is best used in scenarios where a system has a very slow primary disk as it will alleviate a certain amount of disk IO. In systems with relatively small memory configurations, such as 1GB or less and slow disks, ReadyBoost can have a dramatic impact on overall system responsiveness (especially if no other system tweaks have been performed). A systems with lots of physical memory and a fast disk, may see no perceivable improvement from using ReadyBoost and, in some cases, ReadyBoost can actually be detrimental.
The two biggest performance caveats with ReadyBoost are if you are sharing the ReadyBoost devices bus (such as USB) with other bandwidth intensive devices and that ReadyBoost is not entirely free of CPU overhead and said overhead can be dramatic if the bus hosting the ReadyBoost device is serviced by poorly optimized drivers (I have personally seen this with one vendors SD-Reader drivers).
A good example of a non-standard scenario for which ReadyBoost can be quite beneficial is when running a system that is memory constrained because of workload, such as running VirtualPC or VMWare virtual machines (such as for demo purposes on a notebook computer). In this scenario, however, if the ReadyBoost device and the external hard disk being used to run IO intensive apps (such as Virtual Machines) share the same bus, performance of both can be negatively impacted. In this scenario, ideally the ReadyBoost device would be hosted on a separate bus, such as an SD card bus, while the external hard disk would be located on a USB or IEE1394 bus.
The last thing to note about ReadyBoost is that, despite its name, it is not instantaneous in improving performance. On insertion and activation of a ReadyBoost device, or on system reboot, ReadyBoost cache creation takes a number of minutes (2-5 in my experience). During this time, performance may actually be substantially degraded while the cache is being populated.
Additional notes about performance
A couple of quick pointers about what to and what not to do regarding performance tweaking in Vista:
1. Don’t just turn off built in services – most services are necessary and should be left running (though you should try to remove unnecessary 3rd party services, a good example being the iTunes and iPod services Apple installs)
2. DO NOT turn off Aero Glass (or disable the Desktop Window Manager service) – this forces all window management work onto the host CPU (off the GPU) and actually degrades performance dramatically. Only in sub 1GB RAM scenarios should you disable Aero Glass.
3. Do try to leave the pre-configured index and disk defrag settings in place, if at all possible
4. Do make sure you have the latest drivers installed, as Vista’s biggest weak spot at RTM was that drivers were very immature (especially Nvidia’s and Creative’s drivers)
5. Do download AutoRuns from http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx and use it to remove background craplets such as Apple QuickTime and Adobe agents – these agents eat memory and CPU cycles and deliver little value
6. Do use the Windows Resource Monitor to get a quick view of CPU, Disk, Network and Memory activity as this handy utility can be very useful for getting a quick but comprehensive understanding of what applications are consuming resources
7. Provided your system is connected to a UPS, and you have significant physical memory, do “Enable advanced performance” as this increases the systems memory allocated for disk write caching (though do this with caution as in increases the chance of file system corruption and data loss in the event you suddenly lose power)
8. If your system is low-end, 1GB or less with a single core CPU and a slow drive, do disable the Sidebar (yes gadgets are cool, but for low-end systems, they are a waste of cpu cycles)
9. If you are planning to upgrade your system because of poor performance, start by both increasing memory to 2GB, but just as importantly, upgrade to a 7200RPM SATA disk with 16MB of cache, as this will improve performance dramatically (cache being the most important factor)
My final comment for this post is that Windows Vista will never have the same system footprint as Windows XP. Vista, despite all the negative press, and initial launch missteps, is a better Operating System that scales far better than Windows XP thanks to the myriad of core technology improvements. However, with the advent of better scalability (especially on 64bit systems), new functionality (instant search) and better system self maintenance (such as low-impact background filesystem defrag) the OS, as with every new OS iteration, is simply bigger. Windows 2000 was much bigger than NT 4, XP was bigger than both and derided as bloated when it shipped. When OS X shipped, it too was lambasted by more than a few critics as being slow, as it was far larger than its obsolete predecessor. Even Linux is not immune from growth, as a current common Linux distribution is massive compared to a comparable distribution from 5-6 years ago.
So, in short, if you really want a faster version of Windows, perhaps you would like to try Windows 95, as on current hardware, it makes XP look like it’s standing in cement (yeah, I didn’t think so).
