本文共 840 字，大约阅读时间需要 2 分钟。

好久没写文章，最近忙房屋装修，难得闲下来写写blog，想起之前搞得很狼狈的3个性能问题，都是很常见的，记下来引以为戒：

1. 在写系统的i2c driver的时候，从参考板拿来一份轮询的driver sample，改完之后就直接提交代码到系统库，基本的测试都没有问题，一直到系统级别测试，发现和其他系统的交流的某个task A偶尔会timeout，一直找了很久以为是网络有问题，最后无意观看使用Vxworks自带的spy monitor log里面发现当task A timeout的时候，i2c driver task占用CPU百分比很高，而i2c driver task只是简单的读取操作，而且读取次数也不多，仔细查看轮询代码， driver里面在等待i2c返回的时候使用了sysUsDelay，看了UsDelay的实现就是i++.....难怪CPU占用很高，改成中断模式之后问题解决。

2. 第二个问题就更有意思u时候遇到的，折腾了近1个月，在系统的end to end测试中，发现一旦Call的数目上去之后，有一个task的CPU使用率过高，有怀疑过硬件性能不行，也有怀疑过系统压力过大，最后还是看代码看到一个有意思的地方：三重循环。一看到三重循环就很紧张，每次task执行就是368*3*2次循环体，谨遵循环优化办法：把判断条件能外移的外移，同时也把code里面的除法都改成了移位操作。CPU使用过高问题得到解决。

3. 系统压力测试的悲剧：怎么说呢，感觉就是自己太菜，第一次做系统级别的测试，被广告“在cdma的网络里面，Rev A号称3.1mbps的速率”忽悠了。所以系统级别的测试希望手机ftp的速率可以上到3.1mpbs，结果整个系统一直处于崩溃状态，找高通询问他们芯片的处理能力，找自己系统的代码处理能力瓶颈，最后发现overhead没考虑，所以才会出现系统负载不过来的情况，考虑所有的overhead，手机ftp应用最多去到2.7、2.8mbps，我去。。。

转载地址：http://nftmb.baihongyu.com/