好久没写文章，近期忙房屋装修，难得闲下来写写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，我去。。。