decodeURIComponent导致的性能问题
2007-11-14 22:20
288 查看
近两个月,我似乎总在和性能问题打交到。当页面动态展现几千个节点时,又出现了性能问题。
这是个编码比对的功能,省工商局可以选择总局的某一个标准编码类型,系统自动将该类型下的所有编码全部列出,为了增强效果,不允许刷新页面,所有编码项信息以checkbox的形式动态添加。
在几个月前我就完成了这部分功能,加入了页面级的映射校验和映射关系动态添加/删除,我一直以为每个编码类型下至多有几十个编码,我的测试也一直用的是自己添加的20个编码项。直到今天,客户不太熟练的操作着鼠标,不慌不忙地选中了“行政区划”一项,于是——死机了。
没有什么比在演示现场出现死机问题更令人尴尬,这也毫无悬念地遭到了领导们的强烈谴责,这段程序的作者也自然脸上无光。
我一直认为所有的性能问题都有办法解决,第一个念头是大批量的数据展示导致了速度缓慢,那个innerHTML大概没有传说中的那么好用,虽然过去它一直是个好兄弟。但是事实又一次证明,我的第一直觉通常是站不住脚的,问题不在这里。
在动态加载时触发了下面的代码片段:
try...{
PrintWriter printout = response.getWriter();
printout.print(content);
printout.flush();
printout.close();
} catch(IOException e)...{
e.getStackTrace();
}
为了方便的看看content是什么东西,在printout.close();后添加了System.out.println(content);执行一下,意想不到的事发生了,Eclipse挂掉了!连续执行了几次,都出现了Eclipse无响应,难道是PrintWriter的print方法不能写入大量的数据?不太可能。翻翻《Thinking in java》,并没有提到PrintWriter的效率问题,也许是大比量的输出导致。去掉System.out.println(content),加上System.currentTimeMillis(),看看共运行了多久,结果最慢才110,看来PrintWriter并没有效率问题,是System.out.println()输出了太多的东西。那么还是在展示上有问题。
在页面有这样一段代码:decodeURIComponent(returnValue); 这个解码可是极为耗时,我当时为什么要用它呢??? 去掉这句话,速度果然大幅度提高,不到两秒就列出了差不多两米高的编码项,但是全部是encode后的代码,这个就简单了,速度问题已经转换成解码问题。在后台去掉了关于UTF-8的转码,将加载的方法改成:
try...{
response.setContentType("text/html; charset=gbk");
PrintWriter printout = response.getWriter();
printout.print(content);
printout.flush();
printout.close();
} catch(IOException e)...{
e.getStackTrace();
}
于是,世界清净了。当时写代码时我怎么想的?难道真的被马桶盖子夹了脑袋?
在食堂吃饭时看到了一个给索尼做测试的同学,这个家伙在学校时整个一个土鳖,现在居然穿的挺新潮!他老爷的,我周末一定去买件衣服,把他给比下去!
这是个编码比对的功能,省工商局可以选择总局的某一个标准编码类型,系统自动将该类型下的所有编码全部列出,为了增强效果,不允许刷新页面,所有编码项信息以checkbox的形式动态添加。
在几个月前我就完成了这部分功能,加入了页面级的映射校验和映射关系动态添加/删除,我一直以为每个编码类型下至多有几十个编码,我的测试也一直用的是自己添加的20个编码项。直到今天,客户不太熟练的操作着鼠标,不慌不忙地选中了“行政区划”一项,于是——死机了。
没有什么比在演示现场出现死机问题更令人尴尬,这也毫无悬念地遭到了领导们的强烈谴责,这段程序的作者也自然脸上无光。
我一直认为所有的性能问题都有办法解决,第一个念头是大批量的数据展示导致了速度缓慢,那个innerHTML大概没有传说中的那么好用,虽然过去它一直是个好兄弟。但是事实又一次证明,我的第一直觉通常是站不住脚的,问题不在这里。
在动态加载时触发了下面的代码片段:
try...{
PrintWriter printout = response.getWriter();
printout.print(content);
printout.flush();
printout.close();
} catch(IOException e)...{
e.getStackTrace();
}
为了方便的看看content是什么东西,在printout.close();后添加了System.out.println(content);执行一下,意想不到的事发生了,Eclipse挂掉了!连续执行了几次,都出现了Eclipse无响应,难道是PrintWriter的print方法不能写入大量的数据?不太可能。翻翻《Thinking in java》,并没有提到PrintWriter的效率问题,也许是大比量的输出导致。去掉System.out.println(content),加上System.currentTimeMillis(),看看共运行了多久,结果最慢才110,看来PrintWriter并没有效率问题,是System.out.println()输出了太多的东西。那么还是在展示上有问题。
在页面有这样一段代码:decodeURIComponent(returnValue); 这个解码可是极为耗时,我当时为什么要用它呢??? 去掉这句话,速度果然大幅度提高,不到两秒就列出了差不多两米高的编码项,但是全部是encode后的代码,这个就简单了,速度问题已经转换成解码问题。在后台去掉了关于UTF-8的转码,将加载的方法改成:
try...{
response.setContentType("text/html; charset=gbk");
PrintWriter printout = response.getWriter();
printout.print(content);
printout.flush();
printout.close();
} catch(IOException e)...{
e.getStackTrace();
}
于是,世界清净了。当时写代码时我怎么想的?难道真的被马桶盖子夹了脑袋?
在食堂吃饭时看到了一个给索尼做测试的同学,这个家伙在学校时整个一个土鳖,现在居然穿的挺新潮!他老爷的,我周末一定去买件衣服,把他给比下去!
相关文章推荐
- encodeURIComponent编码 URLDecoder.decode解码乱码的问题
- encodeURIComponent编码 URLDecoder.decode解码乱码的问题
- jquery form表单.serialize()序列化后中文乱码问题原因及解决decodeURIComponent
- 前台encodeURIComponent,后台 URLDecoder.decode问题
- encodeURIComponent编码 URLDecoder.decode解码乱码的问题
- 浅析导致数据库性能问题的常见原因
- PHP问题:js中的encodeURIcomponent 函数在php如何实现?
- 一张图看懂encodeURI、encodeURIComponent、decodeURI、decodeURIComponent的区别
- Tomcat Session机制,不及时释放导致内存溢出的性能问题分析
- MySQL Insert语句单个批次数量过多导致的CPU性能问题分析
- 频繁分配释放内存导致的性能问题的分析
- session存放数据过大导致频繁GC影响服务器性能以及高并发问题解决
- url编码有个bug,不能直接用decodeURIComponent,如果遇到前面的$会报错。
- SQL优化_高水位线导致的性能问题
- javascript中escape()、unescape()、encodeURI()、encodeURIComponent()、decodeURI()、decodeURIComponent()比较
- Java 自动装箱导致的性能问题
- 频繁分配释放内存导致的性能问题的分析
- SharePoint 2010 因为证书的原因导致性能问题
- 项目优化经验——垃圾回收导致的性能问题
- JavaScript decodeURI()与decodeURIComponent() 使用与区别