By sampling the Processor Queue Length (I ran the DMS Clarity Tracker Agent in parallel with Clarity Studio and OfficeBench), I was able to determine that this legacy box was only moderately stressed by the workload. With an average Queue Length of three ready threads, the CPU was busy but still not buried under the computing load. In other words, given the workload at hand, the hardware seemed capable of executing it while remaining responsive to the end-user (a trend I saw more of as testing progressed).

The Industrial Revolution: Windows XP/Office 2003
Office 2003 arrived during a time of real upheaval at Microsoft. The company's next major Windows release, code-named Longhorn, was behind schedule and the development team was sidetracked by a string of security breaches in the Windows XP code base. The resulting fix, Windows XP Service Pack 2, was more of a relaunch than a mere update. Whole sections of the OS core were either replaced or rewritten, and new technologies – such as Windows Defender and a revamped firewall – added layers of code to a rapidly bloating platform.

Into this mess walked Office 2003, which, among other things, tried to bridge the gap between Windows and the Web through support for XML and the ability to store documents as HTML files. Unlike Office XP, Office 2003 was not a minor upgrade but a major overhaul of the suite. And the result was, not surprisingly, more bloating of the Windows/Office footprint. Office suite memory consumption went up modestly to 13MB during OfficeBench testing, while CPU utilization remained constant versus previous builds, despite the fact that the suite was spinning an extra four execution threads (the overall thread count was up by 15).

Where the bloat took its toll, however, was in raw application throughput. Completion times under VMware increased another 8 percent vs. Office XP, putting the Windows XP (SP2) and Office 2003 combination a full 25 percent off the pace of the original Windows 2000/Office 2000 numbers from three years earlier. In other words, with all else being equal – hardware, environment, configuration – Microsoft's desktop computing stack was losing in excess of 8 percent throughput per year due to increased code path complexity and other delays. View the overall test results. View more detailed test results at xpnet.com. 

Of course, all else was not equal. Windows XP (SP2) and Office 2003 were born into a world of 3GHz CPUs, 1GB of RAM, SATA disks, and symmetrical multithreading (that is, Intel Hyper-Threading). This added hardware muscle served to offset the growing complexity of Windows and Office, allowing a newer system to achieve OfficeBench times slightly better (about 5 percent) than a legacy Pentium 4 system, despite the latter having a less demanding code path (TGMLC in action once again).

Welcome to the 21st century: Windows Vista/Office 2007
Given the extended delay of Windows Vista and its accompanying Office release, Microsoft Office 2007, I was understandably concerned about the level of bloat that might have slipped into the code base. After all, Microsoft was promising the world with Vista, and early betas of Office showed a radically updated interface (the Office "ribbon") as well as a new, open file format and other nods to the anti-establishment types. Little did I know that Microsoft would eventually trump even my worst predictions. Not only is Vista and Office 2007 the most bloated desktop software stack ever to emerge from Redmond, its system requirements are so out of proportion with recent hardware trends that only the latest and greatest from Intel or AMD can support its epically porcine girth.