因为本人也是该工具的初学者，所以本文的内容可能会浅一些，甚至还包括一些本人的
主观臆测，如果大家有不同意见欢迎指正，呵呵。

Intel VTune的下载地址，请点击这里。

本文所使用的DEMO示例与之前的一篇文章中的DEMO相同，代码链接。

因为本文使用的DEMO是基于Parallel.For，所以会创建一些线程，而这些线程的创建运
行时间会通过Intel VTune的分析结果给出。

首先假设大家已下载并安装了该软件，然后我们通过点击菜单"File"-->"New Project",
会弹出创建项目的提示框，我们选择"Call Graph Wizard"项目类型，并命名为"Parallel_For"
如下图：

在接下来的提示窗口中会提示对什么类型的应用程序进行分析优化，我们选择.Net*
profiling如下图：

然后系统会提示我们.net应用的类型，因为示例代码是.net命令行类型，所以我们选择
“Executable(可执行)”，如下图：

当点击“下一步”按钮会，系统会提示绑定相应的应用程序路径，我们点击“...”按钮
选择DEMO的生成文件路径，如下图：

然后在最后的完成窗口中，我们保持系统默认选项即可，如下图：

到这里，我们点击“完成”按钮，系统会自动运行DEMO的EXE文件，并完成相应的图形绘
制工作。

下面我们看一下其生成的图形化信息：

这里主要看的是各线程模块运行时间信息，当我们将鼠标放在相应的“线程”图标上时，
如下图：

    
     在本DEMO示例中，我们看到线程0的耗时时间是最长的，即1,377,719,162微秒
（注：1秒 = 1,000,000微秒)。我们可以将鼠标放在该线程关联的后续箭头指向的相应.NET模
块，看一下其各个MODULE耗时的长短，比如说“Ex1Task2_UseParallelForMethod”方法：

下面我们再看一下System.Console.ReadLine()方法的耗时,如下图：

通过对比可以看出System.Console.ReadLine()方法要比Ex1Task2_UseParallelForMethod
耗时近10倍，而System.Console.ReadLine()中最耗时的模块调用又是什么呢?见下图:
    

按说找到了最耗时的操作之后只要在Intel VTune中击该模块的鼠标右键，选中弹出菜单的
“View Source”项就会打开相应的源码，然后就可以进行相应的程序优化的。

但因为本例中最耗时的地方在.net框架中的readline模块，因此如在该模块上点击“View
Source”会报错，如下图：

如果此时选择“是”按钮，则Intel VTune会调出“汇编窗口”进行显示：）

当然，除了查看运行时间之外，我发现该软件还可以帮助我们分析.net模块被加载的次数，
比如说我们使用"Ctrl+F"调出查询窗口，在里面输入"get_DefaultScheduler"，如下图：

我们会看到该模块只被加载过一次，并且还就在"线程0"中（双击该方法即可看到），这应
该是在线程池会在创建时初始化的线程调度器,其主要的作用应该就是“管理调度”线程。因此
它只被创建一次（在当前进程下，如果是多进程的话，会在每个进程中初始化一个线程池)。当
然在并行框架中的Task也有相应对象：TaskManager(其采用工作窃取技术让CPU保持全速工
作状态），可以参见园子里这位朋友的文章。

还有就是如果那位朋友有四核处理器或双CPU的机器，也可以跑一下该这DEMO，并测试一
下相应的模块的加载运行时间和次数，看看有什么不同。

本人机器环境:

好的，今天的内容就先到这里了，因为该工具过于强大，只能一步步摸索着使用，所以有
些观点或问题不能完成解释清楚。

Tags:Intel VTune,性能,线程,并行,Parallel

原文链接:http://www.cnblogs.com/daizhj/archive/2009/01/13/1374973.html

作者:代震军,daizhj

网站主页:http://daizhj.cnblogs.com