Figure 2-2. Sample instrumentation analysis code and the actual results. After repeated product runs, module C clearly took the most time.

Based on the instrumentation output shown in Figure 2-2, it was clear that module C had taken the longest, both in total time and average time per run. As you can imagine, the development manager called a meeting with module C's developer. We'll just call her developer C.

As the development manager gave his explanation, developer C grew increasingly and visibly angry. Alarmed at her response, the development manager asked what was wrong. Developer C responded that the problem was not in her code, but rather with the inadequate IO subsystem, which just happened to be configured by the development manager! Developer C went on to say that the reason module C's time was so long was that module C needed to make calls to the IO subsystem, which she had absolutely no control over. So, module C appeared as though it were performing slowly, but the real problem was that the IO subsystem was performing slowly. After a little thought, the development manager agreed. He also said that they needed to ensure there weren't needless IO calls being made, but in principle, he thought developer C was correct.