因为本人也是该工具的初学者,所以本文的内容可能会浅一些,甚至还包括一些本人的主观臆测,如果大家有不同意见欢迎指正,呵呵。
本文所使用的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,并测试一下相应的模块的加载运行时间和次数,看看有什么不同。
本人机器环境:
好的,今天的内容就先到这里了,因为该工具过于强大,只能一步步摸索着使用,所以有些观点或问题不能完成解释清楚。
本文转自 daizhenjun 51CTO博客,原文链接:http://blog.51cto.com/daizhj/127101,如需转载请自行联系原作者