Multi-crash

前两天有朋友问，我的SlimXml有没有和RapidXml对比过效率？我是第一次听说这个库，更不用说对比效率了，于是上他们网站看了下。

好家伙，居然号称比TinyXml快30～60倍，而且是Boost.PropertyTree的默认xml解析器。

于是有点好奇，因为以前也没有特别关心过SlimXml的效率。

于是分别下载了TinyXml-2.6.1和RapidXml-1.13，迅速用vc8建立了两个测试工程，在系统中搜”*.xml”，找到了一个比较合适的测试文件。它足够大（1.5M），utf-8编码并且包含中/英文，有一定层次深度，大约3.3万行。测试文件可以从这里下载

测试对象是三个库从内存字符串解析xml的函数，这样能排除从硬盘上读文件这种不稳定因素的干扰，而且RapidXml貌似只支持从内存里解析

• slim::XmlDocument::loadFromMemory()
• TiXmlDocument::Parse()
• rapidxml::xml_document<char>::parse<flag>()

要说明的是，RapidXml的这个parse是一个模板函数，必须给一个flag的参数，我测试的时候给的是默认的0

测试结果，解析这个3.3万行，1.5M大小的xml，三个库分别花了

• SlimXml:    22ms
• TinyXml:    54ms
• RapidXml: 4ms!

Read more…

把以前写的一个简单的XML parser完善了一下，在google code上共享了。

详情请看这个页面。

我不是所谓开源精神的信奉者。当然我们已经从开源项目中受益很多，比如boost，stlport，apache等等等等，通过阅读优秀的源代码（虽然我本人没怎么干过）无疑可以加速程序员的成长；但是开源不开源完全是人家的自由，没必要极端到认为“私藏代码是邪恶的”吧？

开源的好处之一是会逼迫你去考虑更广泛的用户需求，而不是写出来只要自己会用或者自己的项目组会用就行。这样你就有动力不断的去完善，优化，仔细斟酌每个接口的必要性。

可能有重新发明轮子的嫌疑，在google code的项目托管上搜xml parser能搜到一百多个，但是粗略看了下，全面支持多种编码（multi-byte，utf-8，utf-8 no mark，utf-16，utf-16 big endian）的还真没发现。而最得意的是SlimXml能自动生成Xml文件对应的c++数据结构和读写代码，这样你就不用费尽的挨个找节点读取数据了，只要调用结构的read()，然后所有数据就都在你的结构里了。