项目一开始没有经过性能测试匆忙选用了EasyUI作为前端组件。

由于开发过程中一直采用的Chrome作为开发浏览器，IE下仅作基本兼容性考察。没有重视潜藏的性能问题。

到了项目收尾时，用户进行试用时，发现在IE7、IE8下性能实在太过于不理想，一度我都想重新推倒重新来，但想想几十个页面呢，还是算了。

哎，最终我被迫无奈，尝试通过改源码来提高easyui的效率，此时又遇到一个头疼的难题，easyui的开源代码方法名均为乱码，想要改进，对于我这个只懂基本JS的人来说，难于上青天哇，桑不起！

教训啊，下回开发项目，切勿选择EasyUI。并在选择相应框架前，注意检测一下基本的性能问题。

下面上两张图，给大家看下EasyUI在IE8下的性能。

1.展示的页面：

2.IE8下profiler测出的JS执行时间：

仅仅parse方法就用了6s多的时间，其中大部分时间是在datagrid的解析上，不太明白为什么20行记录也会需要这么久的时间解析。

经过调查发现，datagrid最耗性能的在计算宽度高度上，这个在网上可以找到。但我发现尽管优化之后，性能有了质的飞跃，但总体表现仍然不尽如人意，所以建议开发中还是不要选择easyui的好，可以选择其它jdGrid等插件代替。

除此之外，前期我还发现tree组件也比较耗性能。tree组件在涉及几十上百个节点时在IE7\IE8下性能就相当不行了。优化的方法是：通过异步方法来减少一次加载的节点数，基本上才能满足要求，但操作起来就有点小麻烦了。在新项目上，还是推荐使用zTree之类的成熟插件，上百上千个节点都毫无压力。