Save
保存
Saving a document is generally slower than loading one. The following table summarizes the differences:
保存一个文档总的来说要比载入慢。下面的表格显示了其中的区别：
Sample
样本
Load (milliseconds)
载入（毫秒）
Save (milliseconds)
保存（毫秒）
Difference (percentage)
差别（百分比）
Ado.xml
677
1,441
113
Hamlet.xml
104
184
77
Ot.xml
1,063
1,971
85
Northwind.xml
62
103
66
When saving each sample, the worst case is the attribute-heavy ADO Recordset, which is more than twice as slow as loading it into memory. Given that it seems perfectly reasonable to expect a write operation to be slower than a read operation, these numbers are rather good. But be careful. You can easily strain the file system if you are loading and saving lots of small XML documents, as shown in the section "Free-Threaded Documents."
当保存每一个样本文件时，最糟糕的情况发生在属性比重大的ADO Recordset文件上，它写入时间比载入内存要慢两倍。由于一般认为写操作比读操作慢一些是很合理的，所以以上数字大家都可以接受。但是请注意，如果你载入并保存很多小的XML文档，文件系统很可能会受到影响，正如在“自由线程文档”将要讨论的那样。
Namespaces
名字空间
XML Namespaces also add some overhead in XML parsing time, but not as much as you might think. I have two versions of the Ado.xml example. One uses a namespace prefix "recordset:" on all 2,347 rows, and one does not. The following table shows the difference in load time:
XML名字空间也增加了一些XML解析时的开销，但是并不如你想象得那么多。这里有两个版本的Ado.xml示例。其中一个在2,347行中都使用了“recordset:”前缀，而另一个没有。下面的表格显示了它们在载入时间上的不同：
Measurement
度量
Ado.xml
Ado-ns.xml
Difference (percentage)
差别（百分比）
File size
文件大小
1,007,214
1,030,651
2.3
Load time (milliseconds)
载入时间（毫秒）
662
680
2.7
Most of the difference in load time can be explained by the increase in file size.
Free-Threaded Documents
自由线程文档
A "free-threaded" DOM document (CLSID_DOMFreeThreadedDocument, "Microsoft.FreeThreadedXMLDOM") exposes the same interface as the "rental" threaded document (IID_IXMLDOMDocument). This object can be safely shared across any thread in the same process.
自由线程DOM文档（CLSID_DOMFreeThreadedDocument, "Microsoft.FreeThreadedXMLDOM"）提供了租用线程文档（IID_IXMLDOMDocument）相同的接口。这个对象可以安全的在同一进程中的任意线程间共享。
Free-threaded documents are generally slower than rental documents because of the extra thread safety work they do. You use them when you want to share a document among multiple threads at the same time, avoiding the need for each of those threads to load up their own copy. In some scenarios, this can result in a big win that outweighs the cost of the extra thread safety work.
自由线程文档一般比租用线程文档要慢，因为它要为线程安全性增加开销。如果你想要同时在多个线程中共享文档，可以使用它，以避免在每个线程都要载入自己的拷贝。在某些情况下，这会大大提高性能，即使在线程安全性上有额外的开销。
For example, suppose you have a 2-KB XML file on your Web server, and you have a simple ASP page that loads that file, increments an attribute inside the file, and saves the file again.
例如，假设在你的Web服务器上有一个2KB的XML文件，还有一个简单的ASP页面要载入这个文件，在文件中加入一个属性，然后将它保存。
<%@ LANGUAGE=JSCRIPT %>
<%
Response.Expires = -1;
var filename = Server.MapPath("simple.xml");
Application.Lock();
var doc = Server.CreateObject("Microsoft.XMLDOM");
doc.async = false;
doc.load(filename);
var c = parseInt(doc.documentElement.getAttribute("count"))+1;
doc.documentElement.setAttribute("count",c);
doc.save(filename);
Application.UnLock();
%>
<%=c%>
This ASP code will be completely disk I/O bound. On my Pentium II 450-MHz dual-processor computer, I was not able to get any more than 50 percent CPU utilization. The disk was making a lot of noise.
这段ASP代码会极大的占用磁盘读写通道。在我的Pentium II 450-MHz双处理器的机器上，我不能得到50%以上的CPU使用率。
However, we could bring the file into shared-application state using a free-threaded DOM document, as follows:
但是，我们可以运用自由线程DOM文档将文件可以进行共享，代码如下：
<%@ LANGUAGE=JSCRIPT %>
<%
Response.Expires = -1;
var doc = Application("shared");
if (doc == null)
{
doc = Server.CreateObject("Microsoft.FreeThreadedXMLDOM");
doc.async = false;
doc.load(Server.MapPath("simple.xml"));
Application("shared") = doc;
}
Application.Lock();
var c = parseInt(doc.documentElement.getAttribute("count"))+1;
doc.documentElement.setAttribute("count",c);
Application.UnLock();
%>
<%=c%>
Then we would see the throughput jump dramatically:
这样，我们可以看到吞吐量剧烈的飞跃：
Method
方法
Requests/second
请求/秒
Load/Save
载入/保存
34
Shared
共享
250
In other words, this second approach using the free-threaded DOM document is seven times faster than the other!
可以说，使用了自由线程DOM文档的第二种方法比第一种方法快7倍。
Delayed Memory Cleanup
延迟的内存释放
The one downside to the free-threaded model is that it exhibits more latency in how it cleans up unused memory, affecting the performance of subsequent operations. (Some people report this as a memory leak when in fact it is just delayed cleanup.) The larger the XML document, the more pronounced the latency. The following table shows the increase in load time and working set when using the free-threaded document as opposed to the rental document:
自由线程模式的一个不足是它在释放不使用的内存空间时会有延迟，这影响了后续操作的性能。（有些人将这个现象报告为内存泄漏，事实上，它只是延迟释放内存而已。）XML文档越大，延迟就越显著。下面的表格中显示了使用自由线程同使用租用模式在载入时间和工作空间上的增量：
Sample
样本
Load time (percentage increase)
载入时间（增量百分比）
Working set (percentage increase)
工作空间（增量百分比）
Ado.xml
4
137
Hamlet.xml
23
83
Ot.xml
1
53
Northwind.xml
2
42
These results show that the worst case is when you have many nodes (as in Ado.xml), which makes sense because this generates more memory for the memory manager to clean up. Note that the benefits of being able to share the same document object across threads, as shown above, still outweigh the downside of slower load time and a larger working set.
上述结果表明最坏情况发生在有许多节点的文档上（就像在Ado.xml中的情况）。请注意，能够在线程间共享文档的益处，如上文所示，仍然超过它在载入时间和工作空间上的不利影响。
Virtual Memory
虚拟内存
In the free-threaded model, the working set can spike if you generate enormous amounts of memory for the memory manager to clean up—which can happen when performing XSL transformations on large documents. In this case, you will use up all available memory and strain the virtual memory manager, causing the performance to dramatically decrease. Watch the peak working set of your application under a heavy load to make sure this doesn't happen. If it does, redesign your application by breaking the XML down into smaller chunks. This situation has been improved somewhat in the MSXML January 2000 Web Release. In fact, we got the following reader comment on the January 2000 Web Release page:
在自由线程模式中，工作空间会大大增加，如果你产生了很多需要内存管理去释放的内存，这在进行大文档的XSL转换时会发生。在这种情况下，你会将可用的内存资源用尽，并频繁调用虚存管理器，性能也就急剧下降。你可以通过观察高负荷情况下应用程序的峰值工作空间来确定这种现象不会发生。如果发生了，可将XML拆开成小块，重新设计你的应用程序。这种情况在MSXML January 2000 Web Release中有了些改进。事实上，我们从中得到以下读者评论：
Faster!
更快！
I've done a couple of informal speed trials on server-side transforms (XML to HTML via XSL), and noticed that there's a big improvement.
我做了一些非正式的服务器端转换（通过XSL将XML转换到HTML）速度测试，发现有了巨大的改进。
- Anonymous 9-Feb-2000
- 匿名 2-9，2000
IDispatch
IDispatch
Late-bound scripting languages, such as JScript and VBScript, add a lot of overhead to each method call and property access in the DOM interface. The script engines actually invoke the methods and properties indirectly through the IDispatch interface. First, both script engines call GetIDsOfNames or GetDispID, which will pass in a string name for the method or property and return a DISPID. Then the engines package all the arguments into an array and call Invoke with the DISPID.
晚绑定（late-bound）脚本语言，如JScirpt和VBScirpt，在每次DOM接口的方法调用和属性访问时增加了许多开销。脚本引擎实际上是通过IDispatch接口间接调用方法和属性的。首先，脚本引擎调用GetIDsOfNames或者GetDispID，传入方法和属性名字符串，返回一个DISPID。然后引擎将所有的参数打包到一个数组并以DISPID调用Invoke。
Need I say more? Clearly, this is going to be slower than calling a virtual function in C++ or compiled Visual Basic. Visual Basic is a bit tricky, though, because you can actually do both styles of programming in one application. For example:
需要更多信息？显然，这会比调用C++虚函数或编译的Visual Basic要慢。但是Visual Basic复杂一些，因为你可以在一个应用程序中使用两种编程方式。例如：
Dim doc as Object
set doc = CreateObject("Microsoft.XMLDOM")
...
This is late-bound and will be as slow as VBScript or JScript. To speed this up, from the Project menu, select References and add a reference to the latest version of the "Microsoft XML" library. Then you can write the following early-bound code:
这是晚绑定的，会和VBScript和Jscript一样慢。为了提高速度，按Project菜单，选择References并加入最新版的“Microsoft XML”库。然后你可以写以下早绑定代码：
Dim doc As New MSXML.DOMDocument
...
The other advantage of programming this way is that you'll get all sorts of helpful drop-down lists of available methods and their arguments from Visual Basic.
这种编程方式的另一个优点是你可以在Visual Basic中在下拉列表中得到各种方法名等帮助信息。
