EXT性能问题

       用了两个多月EXT，最近遭遇性能瓶颈，不得不放弃了，或许是我们用的有问题，所以请各位多多指教。

        用最简单的话说就是，我们要用grid一次显示1000条数据，不准用分页，不准修改EXT源代码，可以使用滚动条，显示时间不能超过2秒。

       加载大规模数据不用分页虽然听起来很愚蠢，但是那是用户的要求，因为他们认为Delphi可以做到，Web也可以做到。

      我们采用EXT+Struts+Spring+Hibernate，EXT解析Struts返回的XML串。

      我们的测试结果如下：（四台机器同时访问，机器配置均为P4 3.0，512Mb，有一台是1G，不过时间没有多大差别，每个测试重复三遍，取平均值）

       加载数据量     共耗时（秒）   直接调用Action返回XML耗时（秒）

         20                         2                                        <1

          200                      10                                      2

          700                      20                                      8

          1400                    40                                     17

 

          我在自己的笔记本上测试（Core2 2.0G，2G）

          800                    16

 

          假设总耗时=EXT解析XML时间+EXT绘制DOM元素显示数据时间+调用Action并返回XML时间

          在《Javascript权威指南》中指出IE6.0解析DOM会随数据量增大呈几何级增长。我觉得这个或许是性能瓶颈，而且我们无法克服。

      

           而且在加载大数据量时，IE会瞬时出现假死，而且一碰就会出现“无响应”，我想这对于要求实时性很高，数据量很大，稳定性很高的ERP系统而言，EXT并不能胜任。

           不知道各位有没有好的建议和解决方案。

        

 

         

直接返回html的代碼而不是xml代碼，可以嗎？
這樣不要解析了！

據說ie的元素節點超過5000時會有性能問題，據說，偶不知道是否正確

你可以在firefox下對比測試一下

某些时候,也许innerHTML会很好,尤其性能,再有也许局部引入flash,作一个flash dom交互,因为flash应该有不错的性能,应该会有好表现,试试,其实这就是看到底是客户够bt还是开发人员bt的问题

我机器上firefox，13秒，800条数据。


让EXT在server端生成dom？？

你可以试试不要一次把一千条的dom都绘制出来,这种表格我也用ext做过不过那个时候还是叫 yui-ext 的时候哪时候在他的论坛里面有人弄出来一个叫FastGridView 的扩展 功能就是 第一次加载的时候只绘制 要显示的头 几条记录你拖动下拉筐的时候再显示后面的

嗯，其实有这么个东西也就解决了。多谢了，我去看看。

要一次显示这么多数据，就别想js-ui了，任何web grid都做不到。
滚动逐页显示倒是可以考虑

所以现在想将表现层改为Java桌面程序，现在正在研究如何与Struts通信，不使用Web service，不用EJB，最好能使用现成的控件就像EXT那样访问servlet就成，有这样的东东吗？

URLConnection
调用Struts的Action返回xml
桌面程序处理xml

不知道行不行

发现SWing之类的东西好难用啊，EXT就是模仿的Swing，应该差不多吧。我试一下吧