论坛首页 Web前端技术论坛

使用Dojo的痛苦经历

浏览 52858 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
作者 正文
   发表时间:2008-05-21  
prophet 写道
可以说我们会载入上百个js文件,本地大概10s左右

....考虑做custom build吧,上百个... 合并成一个再做压缩,后台cache. 前台cache,性能会好很多很多。
0 请登录后投票
   发表时间:2008-05-21  
大家都在回避我所提到的致命的问题,就是性能的问题。特别是下面的问题:
shatuo 写道
dojo的渲染机制有没有改善方案,每个页面都渲染两次,特别是第二次,很慢的,几十控件就要近10秒钟,想想办法。

一个页面如果超过10秒,那么是不是会让人跳楼。
我现在做的项目之所以立项,正是因为前面的系统比较慢,所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4,5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上,特别是如果系统使用的越久,就越来越慢。
当然,dojo0.43 是老版本,新版本是不是解决问题,我不敢保证。但是冒然升级到1.1 ,却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo,毕竟性能对我们来说是至关重要。现在正在考虑修改的方案,比较头疼。
0 请登录后投票
   发表时间:2008-05-21  
yiaduo 写道
prophet 写道
可以说我们会载入上百个js文件,本地大概10s左右

....考虑做custom build吧,上百个... 合并成一个再做压缩,后台cache. 前台cache,性能会好很多很多。

下载js的时间对于局域网的应用来说应该不会有太多问题。
而且暂时我们都测试到下载js的时间还是比较短的。但是dojo渲染页面的时间比较长。
0 请登录后投票
   发表时间:2008-05-21  
jelly 写道
yiaduo 写道
prophet 写道
可以说我们会载入上百个js文件,本地大概10s左右

....考虑做custom build吧,上百个... 合并成一个再做压缩,后台cache. 前台cache,性能会好很多很多。

下载js的时间对于局域网的应用来说应该不会有太多问题。
而且暂时我们都测试到下载js的时间还是比较短的。但是dojo渲染页面的时间比较长。


我估计你们是不是大量的应用了诸如contentpane, layoutpane之类的widget,我觉得还是不要使用js做布局管理,那是Css的任务。
0 请登录后投票
   发表时间:2008-05-21  
jelly 写道
大家都在回避我所提到的致命的问题,就是性能的问题。特别是下面的问题:
shatuo 写道
dojo的渲染机制有没有改善方案,每个页面都渲染两次,特别是第二次,很慢的,几十控件就要近10秒钟,想想办法。

一个页面如果超过10秒,那么是不是会让人跳楼。
我现在做的项目之所以立项,正是因为前面的系统比较慢,所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4,5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上,特别是如果系统使用的越久,就越来越慢。
当然,dojo0.43 是老版本,新版本是不是解决问题,我不敢保证。但是冒然升级到1.1 ,却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo,毕竟性能对我们来说是至关重要。现在正在考虑修改的方案,比较头疼。


dojo自带的theme test载入最多也就4,5秒吧,所有的dojo控件都囊括了。如果说你是几十个控件的话,我认为不是一开始页面render都需要解析出来的,比如dialog之类的,完全可以lazy parse的,使用dojo.parse.
0 请登录后投票
   发表时间:2008-05-21  
怎么国内很少使用gwt-ext,
写的全是java代码,编译后全是js+html .界面也很漂亮, 应该爽死了
0 请登录后投票
   发表时间:2008-05-22  
jelly 写道
大家都在回避我所提到的致命的问题,就是性能的问题。特别是下面的问题:
shatuo 写道
dojo的渲染机制有没有改善方案,每个页面都渲染两次,特别是第二次,很慢的,几十控件就要近10秒钟,想想办法。

一个页面如果超过10秒,那么是不是会让人跳楼。
我现在做的项目之所以立项,正是因为前面的系统比较慢,所以性能问题变得无法回避。
现在客户的要求是一搬的页面载入的时间必须4,5s。
特别复杂的页面10多s。
现在即使简单的页面在配置比较差的情况下竟然需要10s以上,特别是如果系统使用的越久,就越来越慢。
当然,dojo0.43 是老版本,新版本是不是解决问题,我不敢保证。但是冒然升级到1.1 ,却也是一个巨大的风险。
现在我们开始考虑暂时放弃dojo,毕竟性能对我们来说是至关重要。现在正在考虑修改的方案,比较头疼。

jelly 我提点比较实际的想法 可能有些唐突

我觉得从你的描述中看 你并没有掌握效率的根本问题
DOJO有很多问题 我也借你的帖子对DOJO小小发泄了一下
不过你想在所要面对的问题 不是将问题推向DOJO 而是搞清楚效率问题究竟出在哪里 对使用DOJO的反思应该留给下一个项目 在找到问题所在之前 试图靠升级框架解决问题是不合适的

页面加载时间仅仅是表面现象 你现在要做的是找出时间瓶颈
首先应该确定的是 时间消耗在CPU时钟上 还是内存页置换上(因为网页内存泄露很多 所以很难说时间不是因为内存申请或者物理内存不足导致的换页耗费的) 如果你不是局域网
而且从你说的"系统使用的越久,就越来越慢" 内存泄露是很有可能的。(如果是DOJO自己内存泄露那就比较麻烦了)

80%的时间消耗在20%的代码上 你应该很清楚这个道理 所以你应该观察时间消耗的位置 是集中于某一个控件 还是平均分布在所有控件上。如果是平均分布,你则应该搞清楚是控件生成的哪个阶段消耗了如此多的时间。

其实网页上CPU长期100%的情况不多 除了死循环和跑一些bt算法 就只有expression能做到了

最坏情况下 你可能需要重新实现某些DOJO的组件。

Good luck.
2 请登录后投票
   发表时间:2008-05-22  
expression 不能用。

需要对代码进行性能和压力测试
最好能逐行 分析。
找到问题的根源再下结论。
0 请登录后投票
   发表时间:2008-05-22  
感觉使用DOJO的人还不在少数啊,可是在这里讨论贴里很少看到DOJO的,基本都是EXT的,是不是现在国内实际做项目的很少用DOJO,是DOJO不适合还是DOJO有些什么问题?EXT既然更改了开放代码的协议,国内商用的机会是不是会大量减少?
0 请登录后投票
   发表时间:2008-05-22  
kimmking 写道
expression 不能用。

需要对代码进行性能和压力测试
最好能逐行 分析。
找到问题的根源再下结论。

dojo的widget问题太多,使用dojo,这些东西都要重新编写,dojo的parse问题也很大,它的那个模板缓存机制也需要改善,总之,使用dojo,挑战就来了。
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics