Kernighan的这一经历是相当典型的 。 “一个程序中不到4%的语句通常占用了一半以上的运行时间 。 ”对许多语言和系统的大量研究表明 ， 对于不处理I/O密集型的大多数程序 ， 大部分的运行时间花在了很小一部分代码上 。 这种模式是下述经验的基础：
Knuth在论文中描述了用行计数性能监视工具进行自我分析的结果 。 性能监视结果表明 ， 一半的运行时间花在了两个循环上 。 结果花了不到一小时修改了几行代码 ， 就让这个性能监视工具的速度提高了一倍 。
性能监视结果说明 ， 一个1000行的程序把80%的时间花在一个5行的子程序上 。 把这个子程序改写成十几行 ， 就让程序的速度提高了一倍 。
1984年贝尔实验室的Tom Szymanski打算给一个大系统提速 ， 结果却使该系统慢了10% 。 他删除了修改的部分 ， 然后多打开了一些性能监视选项以查明失败原因 。 他发现占用的存储空间增加到了原来的20倍 ， 行计数显示存储空间的分配次数远多于释放次数 。 接下来用一条指令就纠正了错误 ， 正确的实现让系统加速了一倍 。
性能监视表明 ， 操作系统一半的时间花在一个只有少数几条指令的循环上 。 改写微代码中的这个循环带来一个量级的提速 ， 但是系统的吞吐量不变：性能组已经优化了系统的空闲循环！
这些经历引出了上一节粗略提到过的一个问题：应当在什么输入上监视程序的性能？查找素数的程序只有一个输入n ， 该输入强烈影响到时间性能监视：对于小的n ， 输入/输出占大头；对于大的n ， 计算占大头 。 有的程序的性能监视结果对输入数据非常不敏感 。 我猜想大多数计算薪水的程序都有相当一致的性能监视结果 ， 至少从2月到11月如此 。 但有的程序的性能监视结果会随输入不同有巨大变化 。 难道你从没有察觉到 ， 你的系统被调整得在制造商的基准数据上运行起来风驰电掣 ， 而处理起你的重要任务时却慢如蜗牛？仔细挑选你的输入数据吧 。
性能监视工具对于性能之外的任务也有用 。 在找素数的练习中 ， 它指出了程序P4的一个错误 。 行计数在估计测试覆盖面时极有价值 ， 比如 ， 如果出现零 ， 则说明有代码未测试 。 DEC公司的Dick Sites这样描述性能监视的其他用途：“(1) 在两层微存储实现中 ， 决定哪些微代码放到芯片上；(2) 贝尔北方研究院（Bell Northern Research）的一位朋友某个周末在带有多重异步任务的实时电话交换软件系统上实现了语句计数 。 通过查看异常计数 ， 他发现了现场安装的代码中存在6处错误 ， 所有错误都涉及不同任务之间的交互 。 其中一处错误用常规调试技术无法成功追踪到 ， 其余错误还没有被当作问题（也就是说 ， 这些错误症状可能已经发生 ， 但是没有人能够将其归结为具体的软件错误） 。 ”
3　专用的性能监视工具到目前为止我们所看到的性能监视工具的原理 ， 适用于从汇编和Fortran直到Ada这样的程序设计语言 ， 但是很多程序员现在使用更强大的语言 。 如何监视Lisp或APL程序的计算性能？又如何监视网络或数据库语言程序的计算性能？
我们打算用UNIX的管道（pipeline）作为更有趣的计算模型的例子 。 管道是一系列的过滤程序（filter）：当数据流经每个过滤程序时 ， 对数据施加变换 。 下面这个经典的管道按照频率递减顺序打印某文件中使用最多的25个单词 。
cat　$*　|tr -cs A-Za-z '\012'　|tr A-Z a-z　|sort　|uniq-c　|sort -r –n |sed 25q当用这个管道在一本大约6万字的书中寻找25个最常见的单词时 ， 我们监视这个管道的性能 。 输出的前6行是：
3463 the1855 a1556 of1374 to1166 in1104 and...下面是对VAX-11/750上计算的“管道性能监视”：
lineswordscharstimes107175970134223314.4u 2.3s18rtr -cs A-Za-z \012576525765130489411.9u 2.2s15rtr A-Z a-z5765257651304894104.9u 7.5s 123rsort576525765130489424.5u 1.6s 27runiq –c 473194616183027.0u 1.6s 31rsort -rn 47319461618300.0u 0.2s 0rsed 25q2550209