性能分析 - Wikiwand
For faster navigation, this Iframe is preloading the Wikiwand page for 性能分析.

性能分析

维基百科,自由的百科全书

软件开发
核心行动
范式与模式
方法论与框架
支持行为
实践
工具
标准与知识体系

软件工程中,性能分析performance analysis也称为profiling),是以收集程序运行时信息为手段研究程序行为的分析方法,是一种动态程式分析英语Dynamic program analysis的方法。

性能分析量测像是程式的空间或时间复杂度特定指令的使用情形英语instruction set simulator、函式呼叫的频率及执行时间等。性能分析的目的在于决定程序的哪个部分应该被优化英语Program optimization,从而提高程序的速度或者内存使用效率。

性能分析可以由程式的源代码或是可执行档进行。一般会使用称为性能分析工具(profiler)的工具进行。性能分析工具会使用许多不同的技术,可能是以事件为基础(Event-based)的、统计的、指令导向的、仿真的方法。性能分析工具常用在性能工程英语Performance engineering的过程中使用。

性能分析工具

CodeAnalyst(英语:CodeAnalyst)性能分析工具的图像输出
CodeAnalyst英语CodeAnalyst性能分析工具的图像输出

"若要了解程式行为,程式分析工具非常重要。电脑架构分析师需要这类工具来评估程式在新的系统结构中运作的情形。软体撰写者需要这类工具来分析程式,并分析出其中关键的区块。编译器撰写者需要这类工具来评估其指令排程分支预测演算法运作的情形" -- (ATOM, PLDI, '94)

性能分析工具使用广泛的技术手段收集数据,包括硬件中断代码指令英语Instrumentation (computer programming)作业系统hooking英语hooking、CPU内置的性能计数寄存器英语Hardware performance counter,等等。

性能分析输出会是:

  • 统计性的事件汇总(轮廓,profile)
汇总的轮廓资讯一般会标示在程式码后面.用一个计数器表示此事件发生的次数,因此汇总的轮廓资讯和程式码长度成正比。
/* ------------ 源代碼------------------------- 發行次數 */            
0001             IF X = "A"                     0055
0002                THEN DO                      
0003                  ADD 1 to XCOUNT           0032
0004                ELSE
0005             IF X = "B"                     0055


  • 所有事件的记录流(亦称踪迹,英文“trace”)
事件的记录流则与指令路径长度英语Instruction path length成线性关系,也就是和运行时长成线性关系。由于资料量过大,有时记录会不切实际。所以,有些程式分析工具可以设定在某特殊条件下才启动事件踪迹的记录,在另外特殊条件下结束事件踪迹的记录。
对于顺序执行的程序,通常轮廓就足够了。但并行计算程序的性能问题(等待消息或者同步问题)和事件的时间顺序有关,因此需要全部的踪迹才能找到问题。
  • hypervisor持续性的互动监控(针对事件连续性或周期性显示在萤幕上)
在观看在执行程式的相关度量时.可在任意时刻启动或结束事件踪迹的记录,也可以在一些关键的点上暂停非同步的程式来看和其他平行处理程式之间的互动关系。

历史

早在1970年代,IBM System/360IBM System/370英语IBM/370的平台就有性能分析工具,一般是用计时器中断在固定的时间纪录程式状态字英语Program status word(PSW)来侦测程式执行时的“过热点”(hot spots)。这是早期使用抽样方式进行性能分析的范例之一。在1974年时,指令集仿真器英语instruction set simulator就允许完整的事件踪迹,以及其他性能监控的机能。

以性能分析工具为主的UNIX程式分析至少可以回溯到1979年,当时Unix系统有一个基础工具prof,可以列出每一个函式,也列出此函式总共花了多少时间。1982年时gprof工具延伸此概念,可以列出完整的函式调用图[1]

1994年时,迪吉多的Amitabh Srivastava和Alan Eustace提出了描述ATOM的论文[2]。ATOM是一个平台,可以将程式配合其性能分析工具调整,在编译期间,ATOM会在要分析的程式中加入程式码,而加入的程式码会输出分析资料,这种修改程式,输出自身分析资料的技术,称为逻辑注入英语Instrumentation (computer programming)

2004年时,gprof和ATOM论文都出现在前50个最具影响力的程式语言设计和实现会议英语Conference on Programming Language Design and Implementation(PLDI)论文中[3]

以输出方式分类

一般性能分析器

一般性能分析器(flat profiler)根据函式呼叫计算平均的函式呼叫次数,而且不会根据被呼叫函数或是执行脉络(context)细分函式呼叫次数。

函式调用图性能分析器

函式调用图会显示函数被呼叫的次数及频率,也会列出函式调用链(call-chains),有些软体会列完整的调用链,有些不会。

以分析方式的分类

性能分析器本身也是程式,可以在被分析程式执行时收集相关资讯,来分析该程式。根据收集到资讯的细微度,以及收集资讯的方式,可以分为事件为基础的性能分析器,或是统计式的性能分析器。有些性能分析器为了收集资讯,会中断程式的执行,因此在时间量测上有一定的解析度限制。

事件为基础的性能分析器

以下列出的程式语言有事件为基础的性能分析器:

  • JavaJVMTI英语Java Virtual Machine Tools Interface(JVM工具介面)API,以前称为JVMPI(JVM性能分析介面),提供给性能分析器的hook,可以抓到像函式呼叫、类别载入、卸载、线程的进入及离开等事件。
  • .NET框架:利用性能分析的API,可以连接到像是COM伺服器的性能分析代理器(profiling agent)。像Java一様,在执行会提供许多回调函式给代理器,可以捕捉到像是方法JIT/进入/离开,物件创建及其他。特别的是性能分析代理器可以用任意方式改写目的应用程式的位元组码。
  • Python:Python的性能分析包括profile模组,以调用函式图为基础的hotshot,以及用'sys.setprofile'函式来捕捉像c_{call,return,exception}及python_{call,return,exception}的事件。
  • Ruby:Ruby也用类似Python的性能分析界面。目前有在profile.rb中的一般效能分析器及相关模组。

统计式的性能分析器

有些性能分析器是用取样的方式运作。取様式的性能分析器利用作业系统中断,在固定时间取様目的程式的程式计数器。取様式的性能分析器在数值上较不精准,但对目的程式执行时间的影响最小,允许目的程式可以在接近全速的速度下运作。

所得到的资料不是精准值,只是统计上的近似值而已。“实际误差的量一般会大于一个取样时间。若某一数值是取様时间的n倍,其误差约为n倍取样时间的平方根。”[4]

在实务上统计式的性能分析器会比其他的分析方式更能知道目的程式各部份占的比例,而且相较之下有较少的边际效应(例如记忆体快取或是指令解码的管道线等),由于统计式的性能分析器对程式执行速度的影响较小。因此可以侦测到一些其他方式侦测不到的问题。这种方式可以看出使用者模式及可中断系统模式(例如系统呼叫)分别占的时间。

不过由于系统程式需处理中断,仍然会花一些CPU的执行周期,分散快取的读取,而且无法分辨在不可中断核心模式下的行为。

有些特制的硬体可以克服这类的问题:有些最近MIPS微理器中,JTAG介面有一个PCSAMPLE暂存器,可以用一种无法侦测到的方式来取様程式计数器。

最常用的统计式的性能分析器包括AMD的CodeAnalyst、苹果公司Shark(OSX)、oprofile(Linux)[来源请求]IntelVTune英语VTune及Parallel Amplifier(Intel Parallel Studio英语Intel Parallel Studio的一部份)。

插装型的性能分析器

有些性能分析可以用插装英语instrumenting(也称为逻辑注入)的方式处理目的程式,也就是在目的程式中加入额外指令来收集需要的资讯。

程式的插装会影响程式的效能,可能会出现不精确的结果及 heisenbug(捉摸不定,不易重现的bug)。插装一定会对程式执行有些影响,常见的情形是使程式变慢。不过插装可以特定只针对部份程式,而且可以小心控制以使影响降到最低。其对于特定程式的影响是看插装放置的位置,以及捕捉踪迹(trace)的机制。有些处理器有硬体支持可以捕捉踪迹,插装可以只占一个机器语言周期的时间。一般可以从结果中移除插装的影响。

gprof是一个同时用插装及取様的性能分析器的例子。插装用来取得被呼叫函式的资讯,而实际花的时间则是由取様方式来获得。

插装是决定性能分析器可控制程度及时间解析度的关键。以下是一些方式的分类。

  • 手动:是由程式设计者加入指令,在执行时计算相关资讯,例如计算事件或是呼叫像是应用程式响应测试英语Application Response Measurement(ARM)标准的API
  • 源代码层级自动处理:依照插装政策,利用自动化工具自动在源代码中加入instrumentation,像Parasoft英语Parasoft公司的Insure++英语Insure++
  • 中间语言:在组合语言或是bytecode中加入针对多种高阶语言的instrumentation,,例如OpenPATOpenPAT英语OpenPATOpenPAT
  • 编译器协助:像gprof和Quantify都是这类的例子,像用gcc -pg ...可以使用gprof,用quantify g++ ...可以使用Quantify。
  • 二进位翻译:此工具在编译好的可执行档中加入instrumentation,例如ATOM。
  • 执行时插装:代码直接在执行前修改,工具可以完成的监控及控制程式的执行,例如用Pin英语Pin (Computer Program)ValgrindDynamoRIO英语DynamoRIO
  • 执行时注入:修改程度比执行时插装要小,代码在执行时修改,令加入跳跃到协助用函式的指令,例如和DynInst英语DynInst

直译器式的插装

  • 直译器式除错选项,可以在直译器处理每个目的指令时,收集性能量度的相关资讯。像字节码控制表JIT的直译器都在目的码执行时有完整的控制能力,因此有机会收集到非常全面的资料。

hypervisor或仿真器

相关条目

参考资料

  1. ^ gprof: a Call Graph Execution Profiler // Proceedings of the SIGPLAN '82 Symposium on Compiler Construction, SIGPLAN Notices, Vol. 17, No 6, pp. 120-126; doi:10.1145/800230.806987
  2. ^ Amitabh Srivastava and Alan Eustace, "Atom: A system for building customized program analysis tools", 1994 (download) // Proceeding PLDI '94 Proceedings of the ACM SIGPLAN 1994 conference on Programming language design and implementation. Pages 196 - 205, doi:10.1145/773473.178260
  3. ^ 20 Years of PLDI (1979–1999): A Selection, Kathryn S. McKinley, Editor
  4. ^ Statistical Inaccuracy of gprof Output 互联网档案馆存档,存档日期2012-05-29.

外部链接

{{bottomLinkPreText}} {{bottomLinkText}}
性能分析
Listen to this article