讨论Ext项目的性能优化

1.js压缩
2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析)
3.解决内存的不释放
ext的性能问题没有多少值得讨论的。

合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。

这些情况是属于极端的...

nihongye 写道

icewubin 写道

nihongye 写道
1.js压缩 2.抛弃iframe,避免了重复解析ext-all.js的开销(据说gzip+ie不会重复解析) 3.解决内存的不释放 ext的性能问题没有多少值得讨论的。 合理利用EXT的组件进行UI设计，因为EXT的不少效果的渲染在IE下性能非常低下，比如超过100行数据的默认grid的渲染，超过200个的column布局的堆砌（这半句我自己都看不懂），动画。。。 这些情况是属于极端的... 啊，没有吧，很多初学EXT的很容易做出个100多行的grid的，用写页面方式做这种表格再正常不过了。 比如：http://fund.eastmoney.com/fund.html 然后又不清楚，这个慢到底是哪个环节造成的，开始乱猜。

说是ext2.2优化了grid的渲染

毛估估测了下，渲染4个表格，每个数据960条，就是
ext-2.2\examples\grid\grid3.html中的本地数据源翻了5倍的结果，耗时23秒（双核迅驰1.6）。

算下来渲染一个500条数据的表格依然要花3秒，在稍微机器性能差一点的环境上，时间一定更长。

先赞一个，性能提高不少，但是依然是有限制的，也就是把原先的200条记录的上限提高到大约450条左右吧，随口估计的。

其实传统table-tr-td的表格也是有上限的，只不过上限比较高，很多人没注意而已。

我的观点:
Ext2.2 的grid , 性能提升微乎其微.
Ext所说的性能优化是纯"视觉系"的.
他只是玩了一个小花招, 延迟渲染了列表行(用了一个"伪异步"的技巧).

EXT在企业应用中，体积应该不成问题。
局域网传输很快，况且有缓存。

令人头疼就是加载速度
就一个普通页面：一棵树，一个20条数据的grid，再加几个form。在奔四，512内存的机器上居然需要3-5秒的加载时间，CPU占用率100%。很是郁闷