分析器的输出结果可能会有多种形式。一种形式是一份标记有每行代码的执行次数的源代
码清单。另一种形式是一份由函数名和该函数被调用的次数组成的清单。第三种形式同样
也是函数清单，不过里面记录的是每个函数的累计执行时间和在每个函数中进行的函数调
用。还有一种形式是一份函数和在每个函数中花费的总时间的清单，但不包括调用其他函
数的时间、调用系统代码的时间和等待事件的时间。
分析器的分析功能都是量身设计的，它自身的性能开销非常小，因此它对程序整体运行时
间的影响也很小。通常，程序中每个操作的执行速度只会被降低几个百分点。第一种方法
的分析结果会非常精确，代价是更高的间接成本和禁用了某些优化。第二种方法的测量结
果是近似值，而且可能会遗漏一些非频繁地被调用的函数，但是它的优点是可以直接运行
于正式产品之上。
分析器的最大优点是它直接显示出了代码中最热点的函数。优化过程被简化为列出需要调查
的函数的清单，确认各个函数优化的可能性，修改代码，然后重新运行代码得到一份新的分
析结果。如此反复，直至没有特别热点的函数或是你无能为力了为止。由于分析结果中的热
点函数从定义上来说就是代码中发生大量计算的地方，因此，通常这个过程是直截了当的。
以我个人的分析经验来看，对调试构建（debug build）的分析结果和对正式构建（release
build）的分析结果是一样的。在某种意义上，调试构建更易于分析，因为其中包含所有的
函数，包括内联函数，而正式构建则会隐藏这些被频繁调用的内联函数。