前些天在做一個(gè)小項(xiàng)目，需要實(shí)現(xiàn)從字符串到XML文件的逆向轉(zhuǎn)換過程。該字符串由XML文件所得。由于使用環(huán)境對解析時(shí)間和內(nèi)存使用量有嚴(yán)格的要求，因此必須確保解析速度和所占用內(nèi)存。
下面簡單敘述一下我的實(shí)現(xiàn)過程。最開始采用的方法是每次從文件字符串里面讀入一個(gè)節(jié)點(diǎn)的值，具體讀取過程有xml文件各個(gè)節(jié)點(diǎn)屬性決定。再利用一個(gè)stack對xml文件節(jié)點(diǎn)進(jìn)行管理。大致思路是每讀入一個(gè)字符串，先判斷其類型，如果是Element或者text, comment, cdata類型則入棧，若為EndElement則出棧，這樣就可以順利建立起各個(gè)父子節(jié)點(diǎn)之間的關(guān)系。
采用這樣的方法是思路比較的明確，實(shí)現(xiàn)起來比較的簡單，缺點(diǎn)是解析速度太慢了，解析一個(gè)2M左右的XML文件要10多分鐘，而且所費(fèi)時(shí)間與文件的大小成幾何級別增長，根本不可能接受。在采用這種方法過程中，也出現(xiàn)了一個(gè)小插曲。就是在解析比較大的xml文件時(shí)，當(dāng)解析的xml節(jié)點(diǎn)超過1500個(gè)時(shí)，就會(huì)導(dǎo)致內(nèi)存分配錯(cuò)誤，堆棧溢出，開始是百思不得其解，后來才知道是由于我在解析字符串過程中，采用了遞歸的方法，因此內(nèi)存消耗很厲害，特別是我開始傳入一個(gè)const字符串時(shí)，一個(gè)小小的幾百K(以200k為例)的文件就可能導(dǎo)致內(nèi)存一下子消耗幾百M(fèi)，因?yàn)槊看沃蛔x入一個(gè)節(jié)點(diǎn)字符串，這樣最終大小可以達(dá)到200K+19.96k+....+0 ~=200*(200-1)k/2~ = 200M.因此導(dǎo)致編譯器堆棧溢出，解決方法有幾種，一是將堆棧設(shè)置大些，另外就是改遞歸為循環(huán)。我采用了后者。
在進(jìn)行字符串解析時(shí)，我大量采用了STL的字符串find,find_first_of()，substr等
函數(shù)，但是這通常只在搜索小字符串時(shí)速度較快，在長達(dá)幾M的字符串時(shí)，由于大塊的內(nèi)存操作，程序運(yùn)行慢如蝸牛。而且我在前面的實(shí)現(xiàn)方法中，每次是提取一個(gè)節(jié)點(diǎn)，然后再進(jìn)行解析，這樣在讀取和解析過程中，會(huì)導(dǎo)致許多重復(fù)的步驟，嚴(yán)重影響工作效率。 于是我就采用一個(gè)了for循環(huán)對讀入的一個(gè)個(gè)字節(jié)進(jìn)行處理，這樣速度得到顯著的提高。但是程序在解析大字符串時(shí)還是運(yùn)行很慢，我開始 意識(shí)到是長字符串的問題，因此得想方法分段解析才行。于是決定每次從字符串里面提取一定的字符處理。在解析長達(dá)幾M的字符串時(shí)，我先后試驗(yàn)了每次提取64bit，128bit，256bit,512bit, 1k, 2k, 4k等不同長度的字符串，發(fā)現(xiàn)在處理大字符串時(shí)，4K的效果最好。在解析一個(gè)8M左右的xml字符串時(shí)，速度可以達(dá)到30S，但是內(nèi)存消耗有點(diǎn)厲害了，達(dá)100M。因此也很難滿足要求。
最后還是采用了一種比較折中的方法，就是在初次解析時(shí)，只解析根節(jié)點(diǎn)以及其下一層子節(jié)點(diǎn)，在保存過程中再分段解析，主要可以極大的減少內(nèi)存消耗，8M左右的文件可以降低到20M左右內(nèi)存。速度也有所提高,最終耗時(shí)3s左右。