on Wed Mar 12 2008, "Marcin Kalicinski" <kalita-AT-poczta.onet.pl> wrote:
I'll try to shed some light on what has happened to property_tree since review and why it's been dragging.
Since review I had some feedback about the library. The issue raised most frequently was unsatisfactory performance. Ptree does too many memory allocations, and thus is fairly slow and unsuitable for many users. Plus some of the original parsers (XML parser specifically) were really slow and took ages to compile, especially on gcc. Because this is headers only library that is supposed to be lightweight, this was a serious problem.
To solve it I spent some months implementing a very fast in-situ XML parser for the library (called rapidxml - see rapidxml project on sourceforge). This was finished in August last year and integrated with property tree. It works very well and is so fast that time to parse XML is now totally insignificant compared to the time it takes to build a ptree from the parsed data.
The allocations problem remains. I have been unable to come up with a scheme that would reduce the number of allocations without compromising simplicty of the library. The key point is that I want to maintain validity of iterators in presence of insertions/erases. This rules out array based containers. The best I can think of is a custom list implementation. That has potential to reduce number of allocations by roughly 30%, which is not enough IMO.
Did you think about using something like http://svn.boost.org/trac/boost/browser/trunk/boost/detail/quick_allocator.h... ?
On top of that I'm not sure whether the heavy type-parametrization of the library (i.e. lots of template parameters everywhere) is a good thing. It definitely makes it harder to document, use and understand. In all the the feedback I got there is no evidence of anyone actually using these template parameters.
That's a good sign that they're not solving any real problems. But we've all made that mistake at one time or another; it can be hard to remember that generic design proceeds from concrete (non-generic) use cases. <snip>
If someone could help with the docs toolchain (Quickbook experts? Any alternatives?) I'm happy to do the rest. I should probably give up on trying to speed it up further and concentrate on getting it into releasable state.
Do you have the help you need, now? -- Dave Abrahams Boost Consulting http://boost-consulting.com