性能测试-函数性能分析篇
-Quantify
在利用ACT（Application Center Test）进行压力测试后，如何对发现性能问题的模块进行定位，发现性能瓶颈所在，这就需要大家了解一个性能分析工具，Rational Test Suite中的Quantify。Quantify是一款面向VB，VC，JAVA的函数级性能分析工具，它可以自动的检测出影响程序运行的性能瓶颈，同时提供图形化的分析表格，帮助程序员进行性能的分析与优化。
在性能优化的过程中，一些程序员往往是凭着经验去分析自己所写的代码，找到性能瓶颈，这样会面临两个问题：
1、 程序员所找到的性能瓶颈的代码很可能是自己认为不合理的算法，但在优化的过程中大家都知道性能的优化往往不是优化算法不合理的，而是主要优化占用时间最长的函数；
2、 在一个大型的项目中，如何在成千上万的代码中找到性能瓶颈是一个最头痛的问题，如果自己不了解所在的项目那就更无法下手；
那么如何高效的提位问题，而不是通过代码的检查发现问题则是关键，而Quantify则是一款这样的神兵利器。
Quantify有以下几个特色：
1、 对当前的开发影响特别的少，还集成在一些通用的开发工具中，大大的增强了使用的容易度，比如Visual Studio;
2、 性能的显示以图形的方式进行，可以很直接的了解到性能所在的瓶颈；
3、 无需源代码就可以对大多数的系统进行性能的分析；
4、 同时显示的函数的信息非常的详细，包含了调用的次数，时间等，还有相关的调用关系；
5、 在测试功能的同时，对性能进行分析，不需要额外的辅助代码；
下面则是通过一个例子来详细的介绍如何使用Quantify进行性能分析并发现问题，这里我用CPPUnit写了一个测试用例，用来测试一段性能有问题的代码（代码就不发出来了，呵呵），主要通过它让大家了解Quantify是一个很简单的工具：
l 对性能的测试只需要运行编译好的程序，如图：
如图1
l 生成的结果如下图2，特别的简单：
如图2
不过要快速的分析，主要有以下几点，首先给大家介绍几个知识，算是了解一下，如果需要详细的了解，这些是远远不够的：
1. Function Time :函数本身执行的时间，它不包含子函数的时间;
2. F+D Time(Function+Descendants):函数本身与函数调用的子函数执行的时间；
3. Calls:函数在执行过程中调用的次数；
4. F Time(%):是函数本身（不包含子函数）占用整个系统运行时间的百分比；
5. F+D Time(%):是函数本身消耗时间加子函数时间占整个调用时间的百分比；
6. Avg F(Time):主要指函数平均运行时间；
7. Min F(Time):函数调用过程中最小的运行时间；
8. Max F(Time):函数调用过程中最大的运行时间；
9. Module:是那个DLL调用的；
在性能分析过程中，有一个原则就是优化占用时间最长的函数或是占百分比最长的函数，所以一般我会先关注Function Time与F Time(%),对此进行排序，从而发现性能上的问题，当然要与自己的系统相关的模块，如图：
如图3
这里你们可以看到与自己系统相关的是系统的输出函数，它的calls次数非常的高，同时占用时间与百分比也非常的多，呵呵，这时你就可以知道这是与系统相关的性能瓶颈，我的代码中也是这样写的，呵呵。
//演示性能测试
void CMabString::DemoPer()
{
cout<<"Begin Performance\n";
int Result =0;
for (int j=0;j<1000;j++)
{
cout<<"This is Performance Test\n";
}
cout<<"End Performance\n";
}
当然你还可以通过图形来发现你的函数由那些子函数组成，如图：
如图4
从这里你可以看到CmabString::DemoPer下面调用的子函数是osteam,调用的次数是1002，占性能的99.80%；同时还可以看到上一级函数，也就是调用CmabString::DemoPer的函数MathTest::testDemPer,通过图形可以看到函数之间的调用关系，同时可以通过关联深入跟踪它的调用关系与性能情况，还是特别的方便的，不过要注意的是，有可能子函数调用的次数与占用的性能甚至可以超过上一级函数，为什么，主要是这里显示了整个过程的调用次数，也就是说可能在其它地方也调用了此调用了此函数，所以这是一个很正常的现象。不过如果对系统不熟或是对工具不熟也会点的晕头转向，我已经晕了不知多少次了，哈哈。上面的例子则是很简单的，就是循环占用了时间。
上面的分析只是定位到函数，但是否可以定位到源码级吗？答案是肯定的。只要有源代码，则可以从源码级进行分析，你可以清楚的看到每一段代码的执行时间，与函数执行时间，通过这种方法你可以更快的定位问题，如下图：
图5
这里LineTime就是这行本身执行时间，Line+D是行执行时间与子树执行的时间，通过源码级的分析可以看到这段代码的性能瓶颈就在for循环内，当然不一定可以优化，但如果可以优化则会提升的最明显。
但性能问题不仅仅是代码[写的不好，还有一些是数据库的问题或是网络传输等等问题，当你发现如果是调用数据库方法出问题或是网络库出问题时，可以转入对网络库或是数据库的分析。
Quantify还有其它很方便的地方，比如分析结果的保存很方便，支持多种语言，当然工具不是万能的，最主要的是人的因素，希望能够通过工具提高你的性能分析能力。
