decodeURIComponent导致的性能问题

       近两个月，我似乎总在和性能问题打交到。当页面动态展现几千个节点时，又出现了性能问题。

       这是个编码比对的功能，省工商局可以选择总局的某一个标准编码类型，系统自动将该类型下的所有编码全部列出，为了增强效果，不允许刷新页面，所有编码项信息以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();
        }

      于是，世界清净了。当时写代码时我怎么想的？难道真的被马桶盖子夹了脑袋？

      在食堂吃饭时看到了一个给索尼做测试的同学，这个家伙在学校时整个一个土鳖，现在居然穿的挺新潮！他老爷的，我周末一定去买件衣服，把他给比下去！