主题：【原创】Javascript、 IE：山而王暴走中 -- 山而王

这两天只睡了10个小时，处于暴走状态。看我能不能理性地将事情说清楚。

我们尊贵无比的顾客大人，小手指头一抬：顺便说一声，你们系统速度太慢。

顾客的心声就是我们的命令。我们查，我们删，我们改，我们暴走。。。

几十年的经验全使上，能加的班全加上，能榨的脑汁全榨出来，提高了。。。。20%。

老板：这不够戏剧化。我要的是令顾客大人一见钟情、或者摔到地上那种提高，至少。。。50%。

我差点摔到地上，含泪：老板，如果不过分的话，能不能把IE的源码买过来？

我的抱怨是有根据的。先说说前提条件：

- IE为每个页面建了一个树型结构，里面存储着该页面所有的HTML COMPONENT

- 如果你有一个HTML COMPONENT，比方说一个TEXTFIELD，它的名字是“山而王”。

- 那么你要控制它的显示时就要用

document.form1.form111.山而王.style.visibility = "visible";

- 另一种访问方式是用可怜的“山而王”做名字，让IE帮你找到这个东东

document.getElementById("山而王").style.visibility = "visible";

我们当然要尽量用第二种访问方式。几百个COMPONENT，多少层LAYER下来，往往一个TABLE EMBEDDING，谁也找不到谁了。

好了，经过我等精心测量，发现：

- 使用第二种方式，也就是说让IE 帮我们找到这个东东，比直接访问要慢无穷多倍，

- 我们干脆自己写了个HASH，存了所有的COMPONENT，用这个方式访问还是比IE 要快10倍。

这简直没有天理了。要知道我们自己写的HASH，只是一个普普通通的Javascript 数据结构，它是在IE之上运行的。作为平台的IE，在检索自己的、已经存储好的数据时，竟然被业余语言Javascript打败？？

这一重大“科技成果”的发现，导致我们可悲地开始建立一个完整的关键字到HTML

COMPONENT映射的HASH。这无疑和IE是重复的，然而效果是明显的。

同样的程序，即使在FIREFOX上运行也比IE要快。在LINUX上更是快一倍。这说明了，IE的数据结构及其搜索方法糟糕透顶。

我很想建议我们的顾客改用FIREFOX，但是我不敢和1千万美金开玩笑。我困沌，我暴走，我垂头丧气。好比一个练习许久的舞蹈者，忽然发现表演的舞台是一堆烂泥。

住在西雅图的兄弟姐妹，有认识比尔。盖茨先生的给捎个话。

就说新泽西的山而王说：

盖子，你的CODE太烂！

现在的浏览器都是把HTML转换成一个DOM对象进行处理，可IE里面的代码都是上个世纪起沉积下来的，XML都是半路出家，和Firefox年轻人没法比啊。

用户估计是以Windows Application的标准要求的，如果你们当初应该给老板或者客户一个效率更低的，现在就好说了，嘿嘿。

MSDN的这篇比较新的东西不知道你看过没有，对提高ajax的性能还是挺有帮助的。

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

发现一个有趣的比较，虽然有点老，但是基本符合事实，在这个对比里，Get elements by id确实是Firefox不多的几个强项之一，大部分都是IE领先。不过没有和Javascript性能最高的Opera进行比较。

Browser performance results from P4 2400MHz CPU, 512MB RAM, Windows 2000. Numbers are in milliseconds.

Last update: Nov 10 2004.

http://www.greymagic.com/dagon/results-nov-04.html

今天就看到了，呵呵；

IE刚出来的时候本质上一个数据块还不能大于64K呢，当然只能用树型的数据结构，实在数据太多了可以把某些个树枝单做一个块处理而不影响整个的数据结构。那时候怎么可以想象写个HASH存了所有的COMPONENTS，万一某个用户的页面是属裹脚布的那不就不活了？

LINUX是基于UNIX的结构，寻址操作的不同（相对DOS/WIN）使得他们确实很有长期发展潜力。但对软件开发者（尤其没什么根基的小公司，新公司）而言，UNIX确实很杀人，根本不可能如期完成开发任务。

把网页转换成树型数据结构，也就是Document Object Model (DOM)，是新一代浏览器的特征，是对新兴起的XML潮流的一个回应，把原来对格式的并不严谨的HTML在浏览器里转化为严格格式化的XML，这样可以使客户端应用的开发更加规范。对早期以处理静态HTML为主的浏览器来说，这样做是没有太多意义的。

http://en.wikipedia.org/wiki/Document_Object_Model

再多说说, 花是大大的有滴.

不过这里有篇国人写的Tips也不错，而且并不只针对客户端的性能改善。

http://blog.joycode.com/demonfox/archive/2006/09/01/82431.aspx

多谢指教。当年我自己很喜欢树这种结构，逻辑性好，可扩展可维护，就是检索麻烦，除非自建索引。好多年不干了，真是三十年河东三十年河西啊。

以前做过一个数据库检索页面，500个结果，每个结果又包含四五十个elements，要求使用Javascript排序，直接用DOM structure寻址还好，一旦用了GetElementByID或者GetElementByName，你就等吧，没个十几分钟机器是不会有反应的...

后来修改了一下sorting algorithm，排序时间缩短到十分钟之内，architect拍板定盘子了：“That's what they asked for, 10 minutes is what they get。”

现在看，如果当时改用Hash，performance能提高10倍？hoho，不可思议... 根本想不到...

IE对于DOM的支持也是烂得一塌糊涂... 共同声讨之...

倒启发了我。要是自己写XML PARSER，不知是不是好一点。

嗯，值得一试。