如何用Instruments来分析应用程序的性能瓶颈
2013-07-10 08:43
288 查看
http://blog.chukong-inc.com/index.php/2012/05/21/如何用instruments来分析应用程序的性能瓶颈/
Published on 2012
年 5 月 21 日, by donglin in C/C++, iOS技术.
Instruments是个性能强大的工具集,包里面自带了多个工具。其中的OpenGL ES Driver工具可以用来分析应用程序中哪些模块给性能造成负担。以XCode4.3+Cocos2d-x工程为例,使用方法如下:
1 Instruments由菜单中的“Profile”方式激活,而“Profile”默认的编译方式是“Release”,ES Driver工具只有在真机设备上才能支持,因此首先在编译选项中,把“Code Signing”中“Release”的证书改为“Developer”使用的证书,否则不能成功运行ES Driver。如下图所示:
2 确定Build的目标是真机设备,然后选择Xcode菜单“Product”的“Profile”,待出现Instruments界面后,选择“Graphics”的“OpenGL ES Driver”。如下图所示:
3 出现主界面后,左边面板上默认选择的是OpenGL ES Driver,现在选择“Sampler”,并从右边面板Call Tree树中的“start”开始逐级展开,就可以看到总运行时间中各模块所占百分比了,值越大,说明该模块消耗的时间越多。如下图所示:
从图上可以看到cocos2d::CCScheduler::update(float)占了总运行时间的91.7%,而它下面又分为3部分,占用的时间比分别为:
57.5% cocos2d::CCParticleSystem:update(float)
32.4% cocos2d::CCTimer:update(float)
1.7% cocos2d::CCActionManager:update(float)
这说明粒子系统和update函数占了消耗时间的大头,虽然不是说大值就一定是性能瓶颈。但这些是还可以逐层展开的,例如update函数,能一直定位到应用程序的模块源代码中,从中看到哪些模块调用了update。
所以通过Instruments的OpenGL ES Driver工具,结合应用程序的源代码本身,思考下各个模块所消耗的时间百分比是不是不当,或者有些模块是不是偏高了,应该是可以做一些有价值的改进的。
如何用Instruments来分析应用程序的性能瓶颈
Published on 2012年 5 月 21 日, by donglin in C/C++, iOS技术.
Instruments是个性能强大的工具集,包里面自带了多个工具。其中的OpenGL ES Driver工具可以用来分析应用程序中哪些模块给性能造成负担。以XCode4.3+Cocos2d-x工程为例,使用方法如下:
1 Instruments由菜单中的“Profile”方式激活,而“Profile”默认的编译方式是“Release”,ES Driver工具只有在真机设备上才能支持,因此首先在编译选项中,把“Code Signing”中“Release”的证书改为“Developer”使用的证书,否则不能成功运行ES Driver。如下图所示:
2 确定Build的目标是真机设备,然后选择Xcode菜单“Product”的“Profile”,待出现Instruments界面后,选择“Graphics”的“OpenGL ES Driver”。如下图所示:
3 出现主界面后,左边面板上默认选择的是OpenGL ES Driver,现在选择“Sampler”,并从右边面板Call Tree树中的“start”开始逐级展开,就可以看到总运行时间中各模块所占百分比了,值越大,说明该模块消耗的时间越多。如下图所示:
从图上可以看到cocos2d::CCScheduler::update(float)占了总运行时间的91.7%,而它下面又分为3部分,占用的时间比分别为:
57.5% cocos2d::CCParticleSystem:update(float)
32.4% cocos2d::CCTimer:update(float)
1.7% cocos2d::CCActionManager:update(float)
这说明粒子系统和update函数占了消耗时间的大头,虽然不是说大值就一定是性能瓶颈。但这些是还可以逐层展开的,例如update函数,能一直定位到应用程序的模块源代码中,从中看到哪些模块调用了update。
所以通过Instruments的OpenGL ES Driver工具,结合应用程序的源代码本身,思考下各个模块所消耗的时间百分比是不是不当,或者有些模块是不是偏高了,应该是可以做一些有价值的改进的。
相关文章推荐
- cluster-proportional-autoscaler源码分析及如何解决KubeDNS性能瓶颈
- MySQL慢SQL优化-如何分析性能瓶颈
- 如何分析系统性能瓶颈(初级)
- linux性能分析及调优__cpu 性能瓶颈调优可调性能参数 、内存性能瓶颈可调性能参数(操作系统设置swap的目的、在写程序时、如何使自己的内存不被换出swap,常驻物理内存)、磁盘I/O可调性能参
- 如何使用strace+pstack利器分析程序性能
- 频繁分配释放内存导致的性能问题的分析 --(附)malloc分配原理浅析 mmap关注焦点 如何优化分配内存
- 性能瓶颈分析
- 性能测试分析之带宽瓶颈的疑惑
- 性能测试瓶颈分析之内存泄漏
- MongoDB 性能瓶颈分析
- 提升 web 应用程序的性能 - 找出瓶颈,加快客户端内容的速度
- linux系统性能优化及瓶颈分析
- 如何分析发生在过去的数据库性能问题
- 如何使用strace+pstack利器分析程序性能
- 监控与性能分析系列:1)strace和ltrace跟踪对比同一个socket应用程序
- 分析影响流媒体服务器性能的硬件瓶颈
- 一个性能瓶颈分析的过程。
- 能使用异步 I/O 大大提高应用程序的性能 学习何时以及如何使用 POSIX AIO API
- 如何分析Analysis中各个图表的含义,写出性能测试报告(继续增加中)
- 性能瓶颈分析方法