First DOM Walk Working Set Delta
第一次DOM树遍历引起的工作空间增量
Walking the DOM tree for the first time has an impact on the working set metric because some nodes in the tree are created on demand. To illustrate this, I'll show the working set deltas resulting from the first walk over the freshly loaded sample data:
在第一次遍历DOM树时，对工作空间这个度量指标会有一定的影响，因为树中有些节点会被创建。为了说明这一点，这里提供了首次遍历载入内存的样品数据时工作空间的增量：
Sample
样品
Working set delta (percentage)
工作空间增量（百分比）
Ado.xml
0
Hamlet.xml
25
Ot.xml
14
Northwind.xml
36
According to these results, it seems that the ADO attribute case doesn't have any nodes created on demand.
以上结果显示，ADO.xml在此时并不需要创建任何节点。
createNode Overhead
createNode的开销
Creating a DOM tree from scratch results in a higher peak working set than loading the same document from disk. To illustrate this, I created a DOM document with 10,000 elements looking like this:
在内存中临时创建一个DOM树比从磁盘上载入同样的文档会产生更高的工作空间峰值。为了说明这一点，这里创建了一个DOM文档，包含10,000个相同的如下元素：
<item>this is a test</item>
Then I compared the load time, load plus walk time (to force on-demand construction), and create time, showing associated working sets.
然后，比较载入时间，载入加遍历时间（强制构造）和直接创建时间，下表显示了相关的工作空间大小：
Function
功能
Time (milliseconds)
时间（单位为毫秒）
Working set (bytes)
工作空间（单位为字节）
Load
146
842,137
Load+Walk
148
1,173,914
Create
740
2,503,066
These results show that loading a document is roughly five times faster than creating the same document from scratch in memory. The reason is that the process of creating a document requires a lot of DOM calls, which slows things down. Merely loading the document bypasses all this and goes directly to the internal data structures.
以上结果显示载入一个文档比在内存中直接创建同样的文档要快差不多5倍。原因是创建文档时需要有多次DOM调用，执行就会变慢。而载入文档就避开了这些，可以直接进入内部数据结构了。
Walk vs. selectSingleNode
遍历与selectSingleNode
The fastest way to walk the tree is to avoid the children collection and any kind of array access. Instead, use firstChild and nextSibling:
最快遍历树的方法是避免子集合和任何数组访问。取而代之的，使用firstChild和nextSibling：
function WalkNodes(node)
{
var child = node.firstChild;
while (child != null)
{
WalkNodes(child);
child = child.nextSibling;
}
}
The following table shows the results for the sample test files—walking all elements, attributes, and text nodes:
以下表格显示了样本文件遍历元素、属性和文本节点的测试结果：
Sample
样本
Walk time (milliseconds)
遍历时间（毫秒）
Number of nodes
节点数量
Nodes/second
节点/秒
Ado.xml
243
63,723
262,234
Hamlet.xml
63
12,100
192,063
Ot.xml
660
118,720
179,878
Northwind.xml
33
6,438
195,090
However, if you are looking for something in the tree, a much faster way to find it is to use XPath via the selectSingleNode or selectNodes methods. For example, I entered an XPath expression "//willnotfindanything", which walked the entire tree and got the following results that show the percentage improvement over a brute force tree walk:
但是，如果你要在树中查找某一事物，更快的方法是通过selectSingleNode或者selectNodes方法使用XPath进行查找。例如，输入一个XPath表达式“//willnotfindanything”进行查找，得到结果的显示出同强制的树的遍历相比改进的百分比：
File
文件
selectSingleNode (milliseconds)
selectSingleNode（毫秒）
Improvement (percentage)
改进（百分比）
Nodes/second
节点/秒
Ado.xml
173
29
368,341
Hamlet.xml
11
82
1,100,000
Ot.xml
113
82
1,050,619
Northwind.xml
5
84
1,287,600
selectSingleNode is faster because it avoids the overhead of calling through the COM layer. Instead of thousands of calls to firstChild and nextSibling, it works by one single call.
selectSingleNode更快是因为它避免了通过COM层调用的总开销。它不必上千次调用firstChild和nextSibling，只需要一次调用就可以了。
Now, this comparison is really not equal: On one hand, selectSingleNode was doing less walking, because it didn't need to look at the text nodes—it could just skip right over them. On the other hand, selectSingleNode was doing more work, because it was comparing each nodeName with the name specified in the query. But you get the idea. In general, selectSingleNode reduces the amount of DOM code you need to write and gives you a noticeable performance improvement.
这个比较事实上并不恰当：一方面，selectSingleNode遍历的开销较少，因为它不需要查看文本字节，只需要跳过它们就可以了。而另一方面，selectSingleNode做了更多的工作，因为它要将查询中指定的名字与每一个nodeName进行比较。但是你应该已经得到一些要点了。总的来说，selectSingleNode降低了你要写的DOM代码，可以带来显著的性能提升。
