2007年6月17日
#
前些天在做一個小項目，需要實現(xiàn)從字符串到XML文件的逆向轉換過程。該字符串由XML文件所得。由于使用環(huán)境對解析時間和內存使用量有嚴格的要求，因此必須確保解析速度和所占用內存。
下面簡單敘述一下我的實現(xiàn)過程。最開始采用的方法是每次從文件字符串里面讀入一個節(jié)點的值，具體讀取過程有xml文件各個節(jié)點屬性決定。再利用一個stack對xml文件節(jié)點進行管理。大致思路是每讀入一個字符串，先判斷其類型，如果是Element或者text, comment, cdata類型則入棧，若為EndElement則出棧，這樣就可以順利建立起各個父子節(jié)點之間的關系。
采用這樣的方法是思路比較的明確，實現(xiàn)起來比較的簡單，缺點是解析速度太慢了，解析一個2M左右的XML文件要10多分鐘，而且所費時間與文件的大小成幾何級別增長，根本不可能接受。在采用這種方法過程中，也出現(xiàn)了一個小插曲。就是在解析比較大的xml文件時，當解析的xml節(jié)點超過1500個時，就會導致內存分配錯誤，堆棧溢出，開始是百思不得其解，后來才知道是由于我在解析字符串過程中，采用了遞歸的方法，因此內存消耗很厲害，特別是我開始傳入一個const字符串時，一個小小的幾百K(以200k為例)的文件就可能導致內存一下子消耗幾百M，因為每次只讀入一個節(jié)點字符串，這樣最終大小可以達到200K+19.96k+....+0 ~=200*(200-1)k/2~ = 200M.因此導致編譯器堆棧溢出，解決方法有幾種，一是將堆棧設置大些，另外就是改遞歸為循環(huán)。我采用了后者。
在進行字符串解析時，我大量采用了STL的字符串find,find_first_of()，substr等
函數(shù)，但是這通常只在搜索小字符串時速度較快，在長達幾M的字符串時，由于大塊的內存操作，程序運行慢如蝸牛。而且我在前面的實現(xiàn)方法中，每次是提取一個節(jié)點，然后再進行解析，這樣在讀取和解析過程中，會導致許多重復的步驟，嚴重影響工作效率。 于是我就采用一個了for循環(huán)對讀入的一個個字節(jié)進行處理，這樣速度得到顯著的提高。但是程序在解析大字符串時還是運行很慢，我開始 意識到是長字符串的問題，因此得想方法分段解析才行。于是決定每次從字符串里面提取一定的字符處理。在解析長達幾M的字符串時，我先后試驗了每次提取64bit，128bit，256bit,512bit, 1k, 2k, 4k等不同長度的字符串，發(fā)現(xiàn)在處理大字符串時，4K的效果最好。在解析一個8M左右的xml字符串時，速度可以達到30S，但是內存消耗有點厲害了，達100M。因此也很難滿足要求。
最后還是采用了一種比較折中的方法，就是在初次解析時，只解析根節(jié)點以及其下一層子節(jié)點，在保存過程中再分段解析，主要可以極大的減少內存消耗，8M左右的文件可以降低到20M左右內存。速度也有所提高,最終耗時3s左右。
2007年5月3日
#
In these days, I used STL in a project, and met several problems. One was caused by erase method. As we know, when we delete a element in a container in STL, the iterator itself will be changed, so the the iterator should be set correctly. A right method can be used as following:
Typedef list<MyClass*>::Iterator myIter;
for(myIter it = listObj.begin(); it != listObj.end();)
if(true)
it = listObj.erase(it);
else
++it;
最近因為項目的需要，將一個應用軟件的底層XML處理模塊進行重寫，由MSDOM改用xmlLite來完成。XmlLite是微軟專門針對C++使用者開發(fā)的一個輕量級開發(fā)包，只具備基本的I/O功能。提供了IXmlReader, IXmlWriter對XML文件進行簡單的讀寫操作。原理很簡單，在讀一個文件時，循環(huán)讀取各個節(jié)點，然后根據(jù)不同的節(jié)點類型讀取其相關屬性數(shù)據(jù)等。XMLLite中的數(shù)據(jù)類型主要封裝在XmlNodeType中，常使用到的有XmlNodeType_None, XmlNodeType_Element,XmlNodeType_EndElement等。在寫數(shù)據(jù)時，主要根據(jù)不同的節(jié)點類型，調用相關的API來完成。值得注意的是，由于XMLLite只提供順序化寫的功能，因此在寫具有多個深度的節(jié)點類型時，需要控制好WriteEndElement()函數(shù)的出現(xiàn)順序等，所以這些都可以通過函數(shù)的遞歸來完成。
由于XmlLite只提供簡單的讀寫等功能，因此，在實際應用中，需要對XMLLite提供的功能進行一定的封裝，從而提供自己的API功能。下面簡單說說我們采用的思路。在讀Xml文件時，需要在加載過程建立XML文件的內部數(shù)據(jù)結構。這可以通過兩種方式來完成，一種是在一個循環(huán)或者遞歸過程中，將整個ＸＭＬｌｏａｄ進來；另外一種方法是一次只加載一層節(jié)點，然后遞歸加載其子節(jié)點。前面一種方法是在處理大XML文件時，可能會有memory footprint問題。所以最終采用了后面的方法。
在實現(xiàn)過程中，我們采用了composite模式來組織XML文件樹結構。通過使用list來建立樹結構。全部操作封裝在一個類中。
有關相關原因，xmlLite的具體封裝實現(xiàn)方法就不提及了。開發(fā)過程中，遇到的主要難點是數(shù)據(jù)的讀寫和保存，關鍵是數(shù)據(jù)結構的處理，其他部分都比較容易。
這我開通blog后的第一篇文章，呵呵，也不知道怎么寫好。以后會盡力寫好點^_^.