XML文檔從格式到大小都是不是確定的。有的可能只有幾行，而有的卻有好幾兆字節(jié)。你也許會(huì)懷疑是不是需要了解XML文檔的大小。而當(dāng)性能成為首要問題時(shí)，知道XML文檔大小就是件必須要作的事情了。

 
從性能角度講，有兩類處理XML文檔的方法。批量處理方式需要較短的時(shí)間，解析成組的文檔。實(shí)時(shí)方式就是實(shí)時(shí)的處理文檔。批處理方式的性能可以通過在一定時(shí)間內(nèi)處理多少文檔來測量，而實(shí)時(shí)模式的性能也采用類似的測量方式，不過是以處理一個(gè)文檔需要多長時(shí)間來計(jì)算的。

Scenarios場景
想象一下，你有一個(gè)實(shí)時(shí)工作的系統(tǒng)，比如一個(gè)Web服務(wù)器。這個(gè)系統(tǒng)需要實(shí)時(shí)的接收客戶發(fā)來的訂單，并需要立即對這個(gè)訂單進(jìn)行響應(yīng)。

這個(gè)系統(tǒng)顯然不能用批量處理的方式進(jìn)行。簡單的估計(jì)一下，假設(shè)這是個(gè)很簡單的訂單，只有十個(gè)項(xiàng)目，這樣所生成的XML文檔就比較小，大概每個(gè)文檔是4KB。這種情況下，使用DOM來解析收到文檔。

如果你的訂單每小時(shí)只有幾個(gè)，那么系統(tǒng)性能對你來說還不是問題。但是長遠(yuǎn)考慮，總有一天訂單的數(shù)量會(huì)多到令你意識到系統(tǒng)性能必須提高。

現(xiàn)在你開始考慮提高性能來適應(yīng)增長的負(fù)荷。你的訂單文檔已經(jīng)很小了，把它們合并成較大的文檔也沒有什么實(shí)際的意義。從縱向考慮，這時(shí)候你可以提高現(xiàn)有系統(tǒng)處理能力；從橫向考慮，你可以增加更多的系統(tǒng)將負(fù)荷分散開。

再看看另一個(gè)完全不同的領(lǐng)域，你現(xiàn)在要處理的是一個(gè)大型的數(shù)據(jù)倉庫。和Web服務(wù)器完全不同，你現(xiàn)在用FTP來傳輸平均大小為300MB的XML文檔。如果還是使用DOM來解析XML文檔，你很快就會(huì)遇到大麻煩。相反，如果你使用SAX就會(huì)好的多，它可以直接解析流入的XML文檔，而不必把它們事先都裝入內(nèi)存。

改變文檔尺寸
有時(shí)候你會(huì)遇到特殊情況需要改變XML文檔大小。想象一下，和剛才一樣你有一個(gè)實(shí)時(shí)處理XML文檔的Web服務(wù)器，而此時(shí)所有的文檔大小都是400MB而不是4KB，你不能使用DOM方式，因?yàn)槟翘純?nèi)存了。可是因?yàn)檫@是個(gè)實(shí)時(shí)系統(tǒng)，性能很重要。你可以使用SAX，不過需要時(shí)間允許并要有強(qiáng)大的處理器。

在這種情況下，你可以通過改變文檔大小來改進(jìn)系統(tǒng)執(zhí)行性能。比如你可以將一個(gè)400MB的文檔分成10個(gè)40MB的，或者40個(gè)10MB的小文檔，這比起處理一個(gè)400MB的文檔更有效率。這樣你就可以使用DOM方式把文件讀入內(nèi)存進(jìn)行處理，及時(shí)響應(yīng)每個(gè)文檔的請求了。同時(shí)還可以清除掉不相關(guān)的文檔。

在批量處理方式上也有類似情況。想象一下你在通過DOM的批處理方式處理數(shù)千個(gè)4KB大小的文檔。最好的方式是將一千個(gè)文件合并成一個(gè)4MB的文件。因?yàn)槊總€(gè)文檔的載入都需要占用系統(tǒng)時(shí)間（不論是DOM還是SAX）。通過將一千個(gè)文檔合并成一個(gè)，你只需要載入一個(gè)文檔，占用的時(shí)間只是原來的千分之一。