Here's how it works. Like CAP, the Working Set Tuner gets called every time a function in your application is called. It assigns each function in your application a bit. This bit is set when the function is called. Periodically, the Working Set Tuner takes a snapshot of all the bits, and then clears them. The default time interval is 1000 milliseconds, but you can adjust this. We find the results are not too sensitive to this parameter, and we rarely change it. If anything, we tend to make it longer if the scenario is very long, to reduce the time spent in the analysis phase by the Working Set Tuner.
The snapshot of the bits tells the Working Set Tuner which functions executed during the last time interval. In sequence, the snapshots give a history of function references over time. Because the bits are cleared after every snapshot, a function with all its bits set is referenced on every snapshot. A function with no bits set was never called during the scenario. Pretty clever, huh?
In the next table we show how this looks. We ran the Working Set Tuner on the Solitaire cascade of cards we discussed in the last chapter. If we were really trying to optimize Solitaire, this is not the scenario we would use: playing a game would have been a much better choice. But playing a game of Solitaire is a tough thing to automate with MS Test, so we chose this simple case instead. For the purposes of this illustration it doesn't matter what we do, because we won't relink Solitaire based on these results. We just want to clarify how the Working Set Tuner operates.
In the next table, each line corresponds to a function. Each function has a row (left-to-right) and each column of 1s and 0s represents a snapshot of each function's activity at that moment.
In the first image, the functions are ordered in the way that they appear in the executable after a normal compile and link of the application. Not all the functions in the program are shown, just the ones at the start of the executable image. Each 0 or 1 corresponds to a Time Interval. The bit is 0 if the function was not referenced during that particular time interval during the cascade, and 1 if it was.
Table 11.2 Function Reference Patterns Before and After Working Set Tuning
Before tuning | After tuning |
00000000000000000000000000000000 | 11111111111111111111111111100000 |
|
In the second column, we show the routines that are at the start of the packing list after tuning the working set. These are all the routines which have 1 bits set anytime during the test. All the rest of the routines in the image were not used during cascade. Notice the string of routines towards the bottom which had only one bit set. These occurred because we moved the mouse across the cascade while it was running. If we had not done this, these routines would have remained scattered throughout the image. If you automate your scenario with MS Test (which you really must do unless you plan to do it by hand every time your application changes), this is one time when some use of the mouse is a good idea. For most applications, you can just pick a screen resolution for the scenario and stick with it. If the screen resolution affects the operation of your application, you can take the time to make your script independent of screen resolution with some clever MS Test programming.
You can see how this works, and that the Working Set tuner does a pretty good job of ordering routines in a rational way, although it is not perfect. The routines at the sixth and the eleventh lines from the bottom should probably have been placed together at the bottom of the list. (If you like, you can fuss with the packing list after running the Working Set Tuner and before linking. It's probably not worth the trouble, but suit yourself.) But using the Working Set Tuner beats the heck out of trying to do it all by hand.