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.

To confirm developer C's hypotheses, they agreed the source code would need to be instrumented at a more granular level. Figure 2-3 shows (for only module A) that, in addition to identifying the module's run time, details such as CPU, IO reads, IO writes, and lock requests would be instrumented.

Figure 2-3. Increased granularity instrumentation example for only module A. Each product's modules have multiple timers implemented, enabling a more detailed time accounting.