从chrome/firefox的测试结果说到性能优化

昨晚上从看jQuery的源代码到写了几个tricky的应用，然后又想试试jQuery一些操作时的效率，进而比较了chrome和firefox两款浏览器的测试结果。

在这个测试结果中两个浏览器似乎看起来不相上下，但是很重要的一个差别是：firefox对两个cpu的使用是不均衡的，一高一低,多次测试都是这样。 而chrome的两个cpu利用率是近乎相同的。

双核，超线程的cpu设计的一个目的就是让一个cpu在满载时还有一个空闲的cpu可以完成其他作业。应用程序出现死循环时有时看到的cpu的值基于25%并轻微上扬波动，那应该敢于大胆猜测如果是4个cpu，基本有一个thread是处于死循环状态了。如果是asp.net的应用程序，基本debug=true了。

现在我们做web都在讲怎么做性能优化，各种各样的front-end和back-end(常见的为web server, cache和db server三部分)的优化的文章/书遍地都是，但是大家有没有考虑过一些问题？比如您的js如果比较耗费client端性能的时候，有没有考虑过将业务逻辑分解以降低该损耗的时间长度？总不能让用户“愉快的上您网站,但是别打开windows media player 11”吧。

优化，Performance Tuning，是一门艺术，我觉得是平衡的艺术。

平衡怎么理解？比如很多人都以“我的stored procedure”执行最快为“性能优化”，其实这差远了，至少，也要把I/O尽可能的降到最低吧。如果再考虑多个影响因素（比如故障处理能力、读写服务器数据交换等），一个优化的过程就是达到目前和以后一段时间内平衡的过程。

Gmail做的比较好的一个地方就是当您的bandwidth不足，机器本身performance很bad等情况下会提示使用basic mode来访问。这个工作看起来是一个功能，但是不如说成是一种优化，这是一个平衡，尊重了client，对server也有好处。

第二个优化的问题是：平时我们的一贯思路是，先做出功能来，需要考虑性能的时候再去优化。那么这个问题带来的最头疼的东西就是没有特明显的性能的问题的时候让你去降低cpu占用率，降低mem占用，怎么办？其实也有办法，抓10个dump一个一个看，相互比较，这两个问题终有被解决的时候。但是，性能问题就是滚雪球，全是细微的地方，你一个一个地方的改吗？每一个你都会觉得“问题不大”，但是“积少成多”，最终只能报告“其实现在网站还好啦... ...”。这时候，平时忽略的问题就成了解决问题的key了，比如，您是否意识到IIS6对静态文件的处理大大落后于IIS7的？您是否意识到IIS6跑asp.net的website去host那些被频繁下载的图片、css等静态文件的性能要低于只host静态文件的website？这些都是小地方，但是带来的结果都一般会show a surprise。

有两个问题：

1. 对于webim的front-end的性能优化/用户体验改进，您如何看待/解决？
2. 对于平日要求功能、要低价程序员（无任何贬低之意，特指那些看到要价低就全盘收进，置项目之外的公司）的项目，是否也是按照先有功能，以后有时间了再重构，再优化，再make better？