>>创建高效的MSXML应用<< 创建高效的MSXML应用code{font-family:"courier new";color:#006}pre{font-family:"courier new";background-color:#e1e1e1;color:#006}a {text-decoration:underline}创建高效的MSXML应用原作：Ben Berck 2002.03.06翻译： onestab 2002.08.03我阅读过几十篇书籍和文章，都是为那些需要用XML做些事情的程序员提供指导的。这些资料对初学XML开发的程序员是有帮助的，并且带有一些短小的例子（都在10KB以下，通常小于1KB）。在这些例子中用到的技术并不总适用于实际开发，尤其是处理特别巨大的文件时。比如，当你需要处理122MB大小的XML文件，每个文件都源于不同的应用程序时会发生什么？这就是我的团队在尝试为公司开发基于服务器的XML执行引擎，以及试验一个允许任何人上传文件并将其转换为XML, SVG,HTML等格式的网站时所面临的两难境地。简言之，我们的目的是要能够处理任何东西，从Microsoft Word到Quark文件，哪个都不算小。显然最先想到的就是增加内存和提高处理器的处理能力。不过这也太容易了些，因为我们想到了大O问题。还记得大学里学过的大O表示法吗？一个算法可以用所占用的处理器周期(时间)和消耗的内存(空间)与其所要处理的元素数量之比来衡量。大O表示法代表了算法固有的适用范围，比如一个时间复杂度为O(n2)或空间复杂度为O(n2)的算法的效率较低，因为它极大地限制了计算机所能处理的问题的规模。当我们试图用一个支持XML DOM的解析器解析一个很大的XML文件时，就首先遇到了这个大O问题。这种方案是将整个XML文件以树型结构装入内存。装入或存储文件所用的时间为O(n)。初看起来似乎可以接受，然而，除了简单的装入文件，要做的事情还有许多。我们还要写代码读这个DOM，分析它，让它干活。我们曾经假定这种分析（比如查找某个元序）所花的时间为O(n)。出乎我们的意料，实际所花的时间是我们无法接受的O(n2)。我们通过分析找出了问题的关键：getItem。这是许多DOM程序员最常用的简单函数。就像检索一个数组一样，这种方法简单而且好用 -- 至少对小的XML文件来说是如此。然而，DOM树实际上更像一个链表，无法随机访问。DOM中这个方法的实现必须要遍历链表。在包含n个元素的链表中循环时，将会有0.5(n2-n)次引用，即O(n2)。从文档中我们很快发现DOM中的另一个函数nextNode也能提供所要的这种功能。我们于是就更改了这行代码，很快就得出了结果（如下表所示）。对于这种大型XML来说，改变一行代码就会显著地提高性能。
文章内容