Inside MSXML Performance(MSXML效能分析) (5) (轉)
Save:namespace prefix = o ns = "urn:schemas--com::office" />
儲存
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
名字空間
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解析時的開銷,但是並不如你想象得那麼多。這裡有兩個版本的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" document (CLSID_DOMFreeThreadedDocument, "Microsoft.FreeThreadedXMLDOM") exposes the same interface as the "rental" threaded document (IID_IXMLDOMDocument). This 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 server, and you have a simple page that loads that file, increments an attribute ins the file, and saves the file again.
例如,假設在你的Web上有一個2KB的XML檔案,還有一個簡單的ASP頁面要載入這個檔案,在檔案中加入一個屬性,然後將它儲存。
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();
%>
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 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文件將檔案可以進行共享,程式碼如下:
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();
%>
Then we would see the throughput jump dramatically:
這樣,我們可以看到吞吐量劇烈的飛躍:
Method
方法
Requests/second
請求/秒
Load/Save
載入/儲存
34
Shared
共享
250
In other s, 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 perfong tranormations 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 , 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 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, 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中在下拉選單中得到各種方法名等幫助資訊。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-991708/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Inside MSXML Performance(MSXML效能分析) (轉)IDEXMLORM
- Inside MSXML Performance(MSXML效能分析) (2) (轉)IDEXMLORM
- Inside MSXML Performance(MSXML效能分析) (3) (轉)IDEXMLORM
- Inside MSXML Performance(MSXML效能分析) (4) (轉)IDEXMLORM
- Inside MSXML Performance(MSXML效能分析) (6) (轉)IDEXMLORM
- Inside MSXML Performance(MSXML效能分析) (7) (轉)IDEXMLORM
- MSXML4預覽版釋出 (轉)XML
- 使用window.performance分析頁面效能ORM
- 前端效能監控-window.performance(轉)前端ORM
- .NET Core 效能分析: xUnit.Performance 簡介ORM
- A Look Inside J2EE Patterns(5) (轉)IDE
- 【前端除錯】- 藉助Performance分析並最佳化效能前端除錯ORM
- Performance --- 前端效能監控ORM前端
- win10系統安裝office出現msxml6.10.1129.0錯誤的解決方法Win10XML
- H5效能分析H5
- 效能監視器- Performance MonitorORM
- iOS-監聽原生H5效能資料window.performanceiOSH5ORM
- oracle performance tunning(5)OracleORM
- Java 效能分析 5 大工具Java
- 效能優化篇 - Performance(工具 & api)優化ORMAPI
- Win10電腦中玩帝國時代3遊戲提示未正確地安裝MSXML4.0怎麼解決Win10遊戲XML
- 遊標指令碼效能問題解決與分析 (4) - Cursor Performance Analysis指令碼ORM
- 遊標指令碼效能問題解決與分析 (2) - Cursor Performance Analysis指令碼ORM
- Flutter效能監控工具(2)— Performance OverlayFlutterORM
- [轉] Android 效能分析案例Android
- inside sqlplus prelim(轉)IDESQL
- MySQL調優效能監控之performance schemaMySqlORM
- 初探 performance – 監控網頁與程式效能ORM網頁
- 【轉載】[效能分析]Oracle資料庫效能模型Oracle資料庫模型
- Linux 效能分析匯總(轉)Linux
- SQL Server效能分析引數 (轉)SQLServer
- 5. MyBatis-Plus效能分析外掛MyBatis
- 5款Java效能分析工具的對比Java
- 前端效能監測,Runtime Performance Debug 技巧前端ORM
- Oracle Performance Tuning 11g2 (5)OracleORM
- Top 5 Database and/or Instance Performance Issues in RAC EnvironmentDatabaseORM
- AIX 下磁碟 I/O 效能分析[轉]AI
- ( 轉)效能測試--地鐵模型分析模型