The Secret Life of SuperFetch

One of the more mysterious new features of Windows Vista is its SuperFetch memory management subsystem. Billed as a "smart" pre-caching mechanism, SuperFetch is supposed to improve system responsiveness by monitoring application usage patterns and then pre-loading application code in anticipation of the next task. SuperFetch uses the time of day and other behavioral markers to determine what to load when, using the Windows memory manager's Standby List as its entry point (the ever illuminating Mark Russinovich goes into more detail in his recent TechNet Article).

Of course, it all sounds good on paper. But how do you quantify the impact of something that's designed to work in the background and to be essentially undetectable (beyond some vague sense that the OS is more responsive)? For starters, it helps to know where to find it. SuperFetch runs as a Windows Service under the SVCHOST alias. The actual filename is sysmain.dll, so a quick scan of Task Manager to correlate the Process ID with the instance of SVCHOST in question gets you in touch with SuperFetch.

Next, you need a way to monitor both SuperFetch's behavior and its impact on system responsiveness. The first part is easy - any Vista-compatible metrics agent will do the trick, though we prefer the one we provide through the xpnet: DMS Clarity Tracker. Measuring the second part - how SuperFetch impacts the system - is a bit trickier.

Here we used another xpnet tool, DMS Clarity Studio, to generate a scripted productivity workload spanning Microsoft Word, Excel, PowerPoint and Internet Explorer. By comparing before/after results with SuperFetch enabled/disabled (and rebooting after each test run) we were able to determine that Microsoft's new VMM magic is indeed having a positive impact on application responsiveness. With the service enabled, Startup times - as measured by the OfficeBench test script - were cut in half, this after multiple "training" runs to allow SuperFetch to map the usage pattern (i.e. "We run Office after booting").

We'll be conducting additional research and testing around SuperFetch and other new Vista technologies (Integrated Search, ReadyBoost) in future blog entries for the exo.performance.network. Stay tuned! Read more...

Monster Excel Workbooks Exposed

Everyone knows that Microsoft Office is a bit of a memory hog. In fact, few products can claim as much credit for driving the memory upgrade cycle as the ubiquitous combination of Word, Excel, PowerPoint and Outlook. However, while many power users may think they’ve pushed the envelope on one or more of these applications – massive documents, huge spreadsheets, media-rich presentations – none can compare to those captains of industry that make their home at the corner of Wall and Broadway.

I’m referring, of course, to financial services traders. The “Type A” personality crowd – risk takers, deal makers, the rock stars of wealth creation. They live life on the edge, balancing risk vs. reward in constant battle with each other and the market itself. And the fuel that drives their engines is…data. Lots and lots of data – analyzed, quantified and extrapolated in nearly every conceivable way.

Massaging that data falls on the shoulders of Microsoft Excel. Through myriad templates and macros and real-time data connections, these traders push Excel to the extreme as they tweak and tune their customized (and highly proprietary) financial models. All of which consumes a tremendous amount of hardware resources. In at least one shop we found that traders ran, on average, six concurrent instances of the Excel application process, each one occupying a peak memory footprint of from 300-500MB during a normal trading session (for a total of 1.8GB).
CPU utilization was also high, with each instance consuming ~60% of the available CPU cycles on a 4-CPU workstation, or 300% out of a total CPU capacity of 400% (100% x 4 CPU). Then there was the thread count. At any given time these systems were asked to juggle up to 230 concurrent execution threads just from the various Excel instances.

That’s approximately 1/2 the total thread workload for a typical business productivity user, yet this is just one application among many. These systems are also running proprietary trading software (plus various real-time feeds, like Bloomberg), which is why even a high-end PC isn’t adequate. Hence their reliance on top-of-the-line workstation hardware. And even then, with dual-cores and gigabytes of memory, many traders still need more than one system in order to handle their computational load. In fact, it’s not uncommon to find 3 or more high-end boxes under a trader’s desk – thanks in large part to the overhead of their massive Excel workbooks.

1.8GB of RAM. 300% CPU utilization. 230 concurrent execution threads. And you thought your spreadsheets were complicated! Read more...