The following example is taken from the early days of the development of Windows NT. The Solitaire program was ported to Windows NT from 16-bit Windows. Initial users of the game complained about its performance when the cards cascade at the end of a winning game. Our first step was to run Performance Monitor. Because we didn't think Solitaire used the network, we logged the data across the network so we didn't interfere with any possible disk activity. We set the time interval to five seconds because the operation we wanted to time takes about 90 seconds. This gave us 18 data points.
To see the Solitaire cascade, it is not necessary to win the game. Start Solitaire and use the keystroke shift+alt+2 to start the cascade.
From the data, it's clear that there is a processor bottleneck. All the other chart lines are flat, except for the LAN activity generated by Performance Monitor. How can we be sure this activity is caused by Performance Monitor? The average NetBEUI Bytes Total/sec (3587) times the length of the run in seconds (340) is just about the size of the Performance Monitor log file (1120260 bytes).
The program was spending 41.445% of the time in privileged mode, and with a high context switch rate. Because the value of File Write Bytes/sec is close to the NetBEUI Bytes Total/sec, we can tell that the File Write Bytes/sec rate was caused by the redirector when it wrote Performance Monitor data. The interrupt rate is consistent with a system connected to a busy network, but not too active on it. We looked at which processes were using the processor.
With the activity from Solitaire and CSRSS, the processor developed the bottleneck. We decided to see if looking at the threads could give us any more information about what was causing this to happen. For clarity, we have omitted the 25 idle or near-idle CSRSS threads from the report shown here.
Now we can see the reasons for the context switches. Solitaire is calling CSRSS constantly, and most of the time is spent in CSRSS running a single thread. The processor is not spending a great deal of time running the Solitaire program. It would appear that Windows NT that has the problem.
By using the WAP profiling tool, no longer included with the Platform SDK but replaced by APIMon, we discovered that Solitaire was making a lot of calls to the GetPixel and SetPixel functions. To continue this Solitaire example, see Using CAP on Solitaire.