实战分析一个性能问题
来源:互联网 发布:d3.js官网下载 编辑:程序博客网 时间:2024/04/30 10:00
------------------------------------------------------------------
大家好,我是Mike,微软拼音的开发工程师。对于很多应用程序来说,性能决定了其成败。所以在其开发过程中,软件工程师会花大量时间来提高性能。下面就一个微软拼音实际性能问题做具体分析。
------------------------------------------------------------------
某阶段,我们的测试工程师经常抱怨使用微软新体验输入风格,当候选窗口使用“竖排”设置时,输入明显变慢;但是横排没有问题。
我们知道,性能差可能有好些原因导致,常见的有:CPU占用过大;内存占用过多导致频繁的页面切换;大量的磁盘访问;死循环;等等。好,那我们先大致确定下什么原因导致性能下降。
很简单,打开Windows的任务管理器,切换到“性能”Tab,如下图:
然后打开记事本,使用微软拼音新体验打字;这时候发现CPU使用历史曲线忽然升高,而内存曲线变化不大。很明显,这很可能是使用竖排设置时,程序某部分占用CPU过大。
下一步,静态分析代码?不太可行,代码量巨大,一两周都不一定能理出头绪。所以我们只能借助性能分析工具(profiler),就像Visual Studio里面的“性能向导”,我们一般用微软内部的性能工具。不过都差不多,基本原理都是对程序进行“Instrumentation”,然后运行程序,再退出程序,这时候profiler会统计所有函数的调用次数,调用时间,生成一个report。下面用Visual Studio 2008 演示一个简单程序来示例如何操作:
1) 点击Analyze菜单下的“Launch Performance Wizard…”,弹出以下对话框
2) 选择“Instrumentation”,点“Next”,直到“Finish”
3) 运行这个程序,结束后,可以看到生成的report
点击“Current View”下拉框,可以看各种统计数据。这时候,我们所要做的就是仔细分析这个report。一种方法是,具体分析哪个函数出问题,选择“Call Stack”,找占用百分比大的函数分析;另一种方法是,切换到“functions”view,按“Exclusive time”排序,找占用时间最多的几个函数。
具体到实际应用程序中,程序很大,可能调用stack非常复杂。这就需要我们熟悉所分析的程序,同时重点关注可能出问题的部分。
具体到我们这个问题,前面分析到竖排候选窗口显示候选词时候,占用CPU过多。沿着这条线一路追下去,最终发现GetTextExtentPoint32这个Windows GDI API占用时间居多。这时候需要返回去查看代码,发现,在竖排情况下,为了计算最大的候选词宽度,某函数将所有候选词计算一遍,在输入简拼时,候选可能有几千个,而这个GDI函数特花时间,所以导致了输入时很慢。
问题找到了,简单的解决方案是:只算最长的几个候选词,得出最大宽度。
大家好,我是Mike,微软拼音的开发工程师。对于很多应用程序来说,性能决定了其成败。所以在其开发过程中,软件工程师会花大量时间来提高性能。下面就一个微软拼音实际性能问题做具体分析。
------------------------------------------------------------------
某阶段,我们的测试工程师经常抱怨使用微软新体验输入风格,当候选窗口使用“竖排”设置时,输入明显变慢;但是横排没有问题。
我们知道,性能差可能有好些原因导致,常见的有:CPU占用过大;内存占用过多导致频繁的页面切换;大量的磁盘访问;死循环;等等。好,那我们先大致确定下什么原因导致性能下降。
很简单,打开Windows的任务管理器,切换到“性能”Tab,如下图:
然后打开记事本,使用微软拼音新体验打字;这时候发现CPU使用历史曲线忽然升高,而内存曲线变化不大。很明显,这很可能是使用竖排设置时,程序某部分占用CPU过大。
下一步,静态分析代码?不太可行,代码量巨大,一两周都不一定能理出头绪。所以我们只能借助性能分析工具(profiler),就像Visual Studio里面的“性能向导”,我们一般用微软内部的性能工具。不过都差不多,基本原理都是对程序进行“Instrumentation”,然后运行程序,再退出程序,这时候profiler会统计所有函数的调用次数,调用时间,生成一个report。下面用Visual Studio 2008 演示一个简单程序来示例如何操作:
1) 点击Analyze菜单下的“Launch Performance Wizard…”,弹出以下对话框
2) 选择“Instrumentation”,点“Next”,直到“Finish”
3) 运行这个程序,结束后,可以看到生成的report
点击“Current View”下拉框,可以看各种统计数据。这时候,我们所要做的就是仔细分析这个report。一种方法是,具体分析哪个函数出问题,选择“Call Stack”,找占用百分比大的函数分析;另一种方法是,切换到“functions”view,按“Exclusive time”排序,找占用时间最多的几个函数。
具体到实际应用程序中,程序很大,可能调用stack非常复杂。这就需要我们熟悉所分析的程序,同时重点关注可能出问题的部分。
具体到我们这个问题,前面分析到竖排候选窗口显示候选词时候,占用CPU过多。沿着这条线一路追下去,最终发现GetTextExtentPoint32这个Windows GDI API占用时间居多。这时候需要返回去查看代码,发现,在竖排情况下,为了计算最大的候选词宽度,某函数将所有候选词计算一遍,在输入简拼时,候选可能有几千个,而这个GDI函数特花时间,所以导致了输入时很慢。
问题找到了,简单的解决方案是:只算最长的几个候选词,得出最大宽度。
0 0
- 实战分析一个性能问题
- 实战分析一个性能问题
- 一个性能问题的分析思路
- 实战现网问题之sql 性能分析及处理
- android性能问题---项目实战
- 数据库性能问题分析
- 性能问题分析
- php性能分析工具xhprof实战
- 一个SOA项目性能分析
- 一个io性能分析案例
- 《WEB性能测试实战》之WEB性能测试分析
- PHP 性能分析第三篇: 性能调优实战
- Android UI性能优化实战 识别绘制中的性能问题
- Android UI性能优化实战 识别绘制中的性能问题
- Android UI性能优化实战 识别绘制中的性能问题
- Android UI性能优化实战 识别绘制中的性能问题
- Android UI性能优化实战 识别绘制中的性能问题
- Android UI性能优化实战 识别绘制中的性能问题
- spring aop的案例(一)日志拦截
- 洛谷P1012 拼数
- 常用链接
- 服务器配置(建站助手),使用MSFTP服务器FTP无法连接解决方法
- Spring+SpringMVC+mybatis+easyui整合实例-----spring mvc整合及mybatis事务部分
- 实战分析一个性能问题
- 在android的service中启动一个通知,点击通知无法启动activity,报一个SecurityException异常
- 基于directshow技术实现的录音程序
- swift 初级 第一个程序 HollowWorld
- DOM对象和jQuery对象之间的相互转换
- asp.net实现word、excel、ppt、pdf在线预览
- IAudioCaptureClient interface
- MMS Host is unreachable
- Spring+SpringMVC+mybatis+easyui整合实例-----easyUI界面部分